- 28 Aug, 2017 1 commit
-
-
Dmitri Shuralyov authored
The IsMetaPackage function was made exported when it was moved from cmd/go to cmd/go/internal/load in CL 36196. Its documentation wasn't updated accordingly. This change fixes that, resolving a golint issue. Updates #18653. Change-Id: Icf89461000754d0f09e6617b11c838e4c050d5a6 Reviewed-on: https://go-review.googlesource.com/59430Reviewed-by: Dave Cheney <dave@cheney.net>
-
- 27 Aug, 2017 1 commit
-
-
Hiroshi Ioka authored
Change-Id: If27f7fbf94ede6f9a57f2520aaf75e6506e0b3f8 Reviewed-on: https://go-review.googlesource.com/59374 Run-TryBot: Dave Cheney <dave@cheney.net> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dave Cheney <dave@cheney.net>
-
- 26 Aug, 2017 2 commits
-
-
Josh Bleecher Snyder authored
One example of a heavily-used zero-size value is encoding/binary.BigEndian. Change-Id: I8e873c447e154ab2ca61b7315df774693891270c Reviewed-on: https://go-review.googlesource.com/59330 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
-
Daniel Martí authored
Went mainly for the ones that make no sense, such as the ones mid-sentence or after commas. Change-Id: Ie245d2c19cc7428a06295635cf6a9482ade25ff0 Reviewed-on: https://go-review.googlesource.com/57293Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 25 Aug, 2017 36 commits
-
-
Joe Tsai authored
Many aspects of the package is woefully undocumented. With the recent flurry of improvements, the package is now at feature parity with the GNU and TAR tools. Thoroughly all of the public API and perform some minor stylistic cleanup in some code segments. Change-Id: Ic892fd72c587f30dfe91d1b25b88c9c8048cc389 Reviewed-on: https://go-review.googlesource.com/59210 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Joe Tsai authored
The PAX specification says the following: <<< 'g' represents global extended header records for the following files in the archive. The format of these extended header records shall be as described in pax Extended Header. Each value shall affect all subsequent files that do not override that value in their own extended header record and until another global extended header record is reached that provides another value for the same field. >>> This CL adds support for parsing and composing global PAX records, but intentionally does not provide support for automatically persisting the global state across files. Changes made: * When Reader encounters a TypeXGlobalRecord header, it parses the PAX records and returns them to the user ad-verbatim. Reader does not store them in its state, ensuring it has no effect on future Next calls. * When Writer receives a TypeXGlobalRecord header, it writes the PAX records to the archive ad-verbatim. It does not store them in its state, ensuring it has no effect on future WriteHeader calls. * The restriction regarding empty record values is lifted since this value is used to represent deletion in global headers. Why provide raw support only: * Some archives in the wild have a global header section (often empty) and it is the user's responsibility to manually read and discard it's body. The logic added here allows users to more easily skip over these sections. * For users that do care about global headers, having access to the raw records allows them to implement the functionality of global headers themselves and manually persist the global state across files. * We can still upgrade to a full implementation in the future. Why we don't provide full support: * Even though the PAX specification describes their operation in detail, both the GNU and BSD tar tools (which are the most common implementations) do not have a consistent interpretation of many details. * Global headers were a controversial feature in PAX, by admission of the specification itself: <<< The concept of a global extended header (typeflag g) was controversial. The typeflag g global headers should not be used with interchange media that could suffer partial data loss in transporting the archive. >>> * Having state persist from entry-to-entry complicates the implementation for a feature that is not widely used and not well supported. Change-Id: I1d904cacc2623ddcaa91525a5470b7dbe226c7e8 Reviewed-on: https://go-review.googlesource.com/59190Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
-
Hiroshi Ioka authored
Change-Id: I6cb0ed9b726da34106ba239b57e2da732a8e1b71 Reviewed-on: https://go-review.googlesource.com/50730Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by: Avelino <t@avelino.xxx>
-
Daniel Martí authored
Otherwise, if there are any parallel tests, it will hang and panic with "all goroutines are asleep - deadlock!". Do not use flag.Uint to handle the error for us because we also want to error on N==0, and because it would make setting the default to GOMAXPROCS(0) more difficult, since it's an int. Check for it right after flag.Parse, and mimic flag errors by printing the usage and returning exit code 2. Fixes #20542. Change-Id: I0c9d4587f83d406a8f5e42ed74e40be46d639ffb Reviewed-on: https://go-review.googlesource.com/54150 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Meir Fischer authored
This addresses the case of a -timeout panic, but not the more general case of a signal arriving. See CL 48370 and CL 44352 for recent difficulties in that area. "-timeout" here means flag usage to distinguish from the default timeout termination which uses signals. Fixes #19394 Change-Id: I5452d5422c0c080e940cbcc8c6606049975268c6 Reviewed-on: https://go-review.googlesource.com/48491Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Artyom Pervukhin authored
Closes #21519 Change-Id: I1247e9435de93aae7e4db2b6e8e5be1b010c296b Reviewed-on: https://go-review.googlesource.com/56832Reviewed-by: Avelino <t@avelino.xxx> Reviewed-by: Adam Langley <agl@golang.org>
-
Joe Tsai authored
This CL adds the following new publicly visible API: type Header struct { ...; PAXRecords map[string]string } The new Header.PAXRecords field is a map of all PAX extended header records. We suggest (but do not enforce) that users use VENDOR-prefixed keys according to the following in the PAX specification: <<< The standard developers have reserved keyword name space for vendor extensions. It is suggested that the format to be used is: VENDOR.keyword where VENDOR is the name of the vendor or organization in all uppercase letters. >>> When reading, the Header.PAXRecords is populated with all PAX records encountered so far, including basic ones (e.g., "path", "mtime", etc). When writing, the fields of Header will be merged into PAXRecords, overwriting any records that may conflict. Since PAXRecords is a more expressive feature than Xattrs and is entirely a superset of Xattrs, we mark Xattrs as deprecated, and steer users towards the new PAXRecords API. The issue has a discussion about adding a Header.SetPAXRecord method to help validate records and keep the Header fields in sync. However, we do not include that in this CL since that helper method can always be added in the future. There is no support for global records. Fixes #14472 Change-Id: If285a52749acc733476cf75a2c7ad15bc1542071 Reviewed-on: https://go-review.googlesource.com/58390 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Joe Tsai authored
Add this early in the cycle so that we can start regression testing of the master toolchain. Change-Id: Ida3ccad6e9642648f489babd12877fc8a5eca07a Reviewed-on: https://go-review.googlesource.com/59151Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
Change-Id: I8e8a3a118b1216f191c9076b70a88f6f3f19f79f Reviewed-on: https://go-review.googlesource.com/59150 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Borja Clemente authored
Fixes #21570 Change-Id: Ia0734929a04fbce8fdd5fbcb1b7baff9a8bbe39e Reviewed-on: https://go-review.googlesource.com/58030Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Tom Levy authored
If Less(a, b) returns true when a is less than b, the correct way to check if a is greater than b is to use Less(b, a). It is wrong to use !Less(a, b) because that checks if a is greater than *or equal to* b. 1. The decreasingDistance function in Example_sortKeys makes this mistake. Fix it. 2. The documentation of multiSorter.Less says it loops along the less functions until it finds a comparison "that is either Less or !Less". This is nonsense, because (Less(a, b) or !Less(a, b)) is always true. Fix the documentation to say that it finds a comparison "that discriminates between the two items (one is less than the other)". The implementation already does this correctly. Change-Id: If52b79f68e4fdb0d1095edf29bdecdf154a61b8d Reviewed-on: https://go-review.googlesource.com/57752Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
fanzha02 authored
The current code treats the type of SIMD&FP register as C_REG incorrectly. The fix code converts C_REG type into C_FREG type. Uncomment fcsels/fcseld test cases. Fixes #21582 Change-Id: I754c51f72a0418bd352cbc0f7740f14cc599c72d Reviewed-on: https://go-review.googlesource.com/58350Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Heschi Kreinick authored
Fix two small but serious bugs in the DWARF location list code that should have been caught by the automated tests I didn't write. After emitting debug information for a user variable, mark it as done so that it doesn't get emitted again. Otherwise it would be written once per slot it was decomposed into. Correct a merge error in CL 44350: the location list abbreviations need to have DW_AT_decl_line too, otherwise the resulting DWARF is gibberish. Change-Id: I6ab4b8b32b7870981dac80eadf0ebfc4015ccb01 Reviewed-on: https://go-review.googlesource.com/59070 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
jaredculp authored
Change-Id: Ic3ce2f3c055f2636ec8fc9cec8592e596b18dc05 Reviewed-on: https://go-review.googlesource.com/54771 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Wei Xiao authored
Use "STP (ZR, ZR), O(R)" instead of "MOVD ZR, O(R)" to implement memory clearing. Also improve assembler supports to STP/LDP. Results (A57@2GHzx8): benchmark old ns/op new ns/op delta BenchmarkClearFat8-8 1.00 1.00 +0.00% BenchmarkClearFat12-8 1.01 1.01 +0.00% BenchmarkClearFat16-8 1.01 1.01 +0.00% BenchmarkClearFat24-8 1.52 1.52 +0.00% BenchmarkClearFat32-8 3.00 2.02 -32.67% BenchmarkClearFat40-8 3.50 2.52 -28.00% BenchmarkClearFat48-8 3.50 3.03 -13.43% BenchmarkClearFat56-8 4.00 3.50 -12.50% BenchmarkClearFat64-8 4.25 4.00 -5.88% BenchmarkClearFat128-8 8.01 8.01 +0.00% BenchmarkClearFat256-8 16.1 16.0 -0.62% BenchmarkClearFat512-8 32.1 32.0 -0.31% BenchmarkClearFat1024-8 64.1 64.1 +0.00% Change-Id: Ie5f5eac271ff685884775005825f206167a5c146 Reviewed-on: https://go-review.googlesource.com/55610 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Ilya Tocar authored
Sometimes (often for calls) we generate code like this: MOVQ (addr),AX MOVQ 8(addr),BX MOVQ AX,(otheraddr) MOVQ BX,8(otheraddr) Replace it with MOVUPS (addr),X0 MOVUPS X0,(otheraddr) For completeness do the same for 8,16,32-bit loads/stores too. Shaves 1% from code sections of go tool. /localdisk/itocar/golang/bin/go 10293917 go_old 10334877 [40960 bytes] read-only data = 682 bytes (0.040769%) global text (code) = 38961 bytes (1.036503%) Total difference 39643 bytes (0.674628%) Updates #6853 Change-Id: I1f0d2f60273a63a079b58927cd1c4e3429d2e7ae Reviewed-on: https://go-review.googlesource.com/57130 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
griesemer authored
Throughout the spec we use the notion of a constant x being representable by a value of type T. While intuitively clear, at least for floating-point and complex constants types, the concept was not well-defined. In the section on Conversions there was an extra rule for floating-point types only and it missed the case of floating-point values overflowing to an infinity after rounding. Since the concept is important to Go, and a compiler most certainly will have a function to test "representability", it seems warranted to define the term explicitly in the spec. This change introduces a new entry "Representability" under the section on "Properties of types and values", and defines the term explicitly, together with examples. The phrase used is "representable by" rather than "representable as" because the former use is prevalent in the spec. Additionally, it clarifies that a floating-point constant that overflows to an infinity after rounding is never representable by a value of a floating-point type, even though infinities are valid values of IEEE floating point types. This is required because there are not infinite value constants in the language (like there is also no -0.0) and representability also matters for constant conversions. This is not a language change, and type-checkers have been following this rule before. The change also introduces links throughout the spec to the new section as appropriate and removes duplicate text and examples elsewhere (Constants and Conversions sections), leading to simplifications in the relevant paragraphs. Fixes #15389. Change-Id: I8be0e071552df0f18998ef4c5ef521f64ffe8c44 Reviewed-on: https://go-review.googlesource.com/57530Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Josh Bleecher Snyder authored
Prior to this change, we use typedmemmove to write the key value to its new location in mapassign_fast32 and mapassign_fast64. (The use of typedmemmove was a last-minute fix in the 1.9 cycle; see #21297 and CL 53414.) This is significantly less inefficient than direct assignment or calling writebarrierptr directly. Fortunately, there aren't many cases to consider. On systems with 32 bit pointers: * A 32 bit AMEM value either is a single pointer or has no pointers. * A 64 bit AMEM value may contain a pointer at the beginning, a pointer at 32 bits, or two pointers. On systems with 64 bit pointers: * A 32 bit AMEM value contains no pointers. * A 64 bit AMEM value either is a single pointer or has no pointers. All combinations except the 32 bit pointers / 64 bit AMEM value are cheap and easy to handle, and the problematic case is likely rare. The most popular map keys appear to be ints and pointers. So we handle them exhaustively. The sys.PtrSize checks are constant branches and are eliminated by the compiler. An alternative fix would be to return a pointer to the key, and have the calling code do the assignment, at which point the compiler would have full type information. Initial tests suggest that the performance difference between these strategies is negligible, and this fix is considerably simpler, and has much less impact on binary size. Fixes #21321 Change-Id: Ib03200e89e2324dd3c76d041131447df66f22bfe Reviewed-on: https://go-review.googlesource.com/59110 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
Follow-up to CL 58371. Change-Id: I3d2aaec84ee6db3ef1bd4fcfcaf46cc297c7176b Reviewed-on: https://go-review.googlesource.com/58610 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Keith Randall authored
Implement int reg <-> fp reg moves on amd64. If we see a load to int reg followed by an int->fp move, then we can just load to the fp reg instead. Same for stores. math.Abs is now: MOVQ "".x+8(SP), AX SHLQ $1, AX SHRQ $1, AX MOVQ AX, "".~r1+16(SP) math.Copysign is now: MOVQ "".x+8(SP), AX SHLQ $1, AX SHRQ $1, AX MOVQ "".y+16(SP), CX SHRQ $63, CX SHLQ $63, CX ORQ CX, AX MOVQ AX, "".~r2+24(SP) math.Float64bits is now: MOVSD "".x+8(SP), X0 MOVSD X0, "".~r1+16(SP) (it would be nicer to use a non-SSE reg for this, nothing is perfect) And due to the fix for #21440, the inlined version of these improve as well. name old time/op new time/op delta Abs 1.38ns ± 5% 0.89ns ±10% -35.54% (p=0.000 n=10+10) Copysign 1.56ns ± 7% 1.35ns ± 6% -13.77% (p=0.000 n=9+10) Fixes #13095 Change-Id: Ibd7f2792412a6668608780b0688a77062e1f1499 Reviewed-on: https://go-review.googlesource.com/58732 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
-
Kevin Burke authored
Make it dead simple to see visually what the function outputs in various scenarios. Change-Id: I8f6fcd72fa1515361481f0510412cde221e1d4e3 Reviewed-on: https://go-review.googlesource.com/51630 Run-TryBot: Kevin Burke <kev@inburke.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Hiroshi Ioka <hirochachacha@gmail.com>
-
Austin Clements authored
CL 36428 changed the way nanotime works so on Darwin and Windows it now depends on runtime.startNano, which is computed at runtime.init time. Unfortunately, the `runtimeInitTime = nanotime()` initialization happened *before* runtime.init, so on these platforms runtimeInitTime is set incorrectly. The one (and only) consequence of this is that the start time printed in gctrace lines is bogus: gc 1 18446653480.186s 0%: 0.092+0.47+0.038 ms clock, 0.37+0.15/0.81/1.8+0.15 ms cpu, 4->4->1 MB, 5 MB goal, 8 P To fix this, this commit moves the runtimeInitTime initialization to shortly after runtime.init, at which point nanotime is safe to use. This also requires changing the condition in newproc1 that currently uses runtimeInitTime != 0 simply to detect whether or not the main M has started. Since runtimeInitTime could genuinely be 0 now, this introduces a separate flag to newproc1. Fixes #21554. Change-Id: Id874a4b912d3fa3d22f58d01b31ffb3548266d3b Reviewed-on: https://go-review.googlesource.com/58690 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Hana Kim authored
Generated with github.com/catapult/tracing/bin/vulcanize_trace_viewer catapult @ ab4d571fa Renamed trace_viewer_lean.html to trace_viewer_full.html to make it clear we are using the full version of trace viewer (waiting for https://github.com/catapult-project/catapult/issues/2247 to be fixed). Update #15302 Change-Id: Ice808bb27ab79a1dec9fc863e0c5a761027ebfbe Reviewed-on: https://go-review.googlesource.com/58750Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
-
Wei Xiao authored
Updates #21486 Change-Id: I78ca76490d8e9b52e055c1f0b8d10bdb227e3a80 Reviewed-on: https://go-review.googlesource.com/56331Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Danny Rosseau authored
Fix debugger printing of uint that mistakenly invoked .int64() instead of .uint64() Fixes #21392 Change-Id: I107a7e87e0efbb06303c1e627dee76c369f75d1e Reviewed-on: https://go-review.googlesource.com/54750Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Rob Pike <r@golang.org> Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Aliaksandr Valialkin authored
Benchmark results on GOOS=linux: GOARCH=amd64 name old time/op new time/op delta Atoi/Pos/7bit-4 20.1ns ± 2% 8.6ns ± 1% -57.34% (p=0.000 n=10+10) Atoi/Pos/26bit-4 25.8ns ± 7% 11.9ns ± 0% -53.91% (p=0.000 n=10+8) Atoi/Pos/31bit-4 27.3ns ± 2% 13.2ns ± 1% -51.56% (p=0.000 n=10+10) Atoi/Pos/56bit-4 37.2ns ± 5% 18.2ns ± 1% -51.26% (p=0.000 n=10+10) Atoi/Pos/63bit-4 38.7ns ± 1% 38.6ns ± 1% ~ (p=0.297 n=9+10) Atoi/Neg/7bit-4 17.6ns ± 1% 7.2ns ± 0% -59.22% (p=0.000 n=10+10) Atoi/Neg/26bit-4 24.4ns ± 1% 12.4ns ± 1% -49.28% (p=0.000 n=10+10) Atoi/Neg/31bit-4 26.9ns ± 0% 14.0ns ± 1% -47.88% (p=0.000 n=7+10) Atoi/Neg/56bit-4 36.2ns ± 1% 19.5ns ± 0% -46.24% (p=0.000 n=10+9) Atoi/Neg/63bit-4 38.9ns ± 1% 38.8ns ± 1% ~ (p=0.385 n=9+10) GOARCH=386 name old time/op new time/op delta Atoi/Pos/7bit-4 89.6ns ± 1% 8.2ns ± 1% -90.84% (p=0.000 n=9+10) Atoi/Pos/26bit-4 187ns ± 2% 12ns ± 1% -93.71% (p=0.000 n=10+9) Atoi/Pos/31bit-4 225ns ± 1% 225ns ± 1% ~ (p=0.995 n=10+10) Atoi/Neg/7bit-4 86.2ns ± 1% 8.5ns ± 1% -90.14% (p=0.000 n=10+10) Atoi/Neg/26bit-4 183ns ± 1% 13ns ± 1% -92.77% (p=0.000 n=9+10) Atoi/Neg/31bit-4 223ns ± 0% 223ns ± 0% ~ (p=0.247 n=8+9) Fixes #20557 Change-Id: Ib6245d88cffd4b037419e2bf8e4a71b86c6d773f Reviewed-on: https://go-review.googlesource.com/44692Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Matthew Dempsky authored
Since golang.org/cl/31670, we've stopped using the 'embedded' function for handling struct embeddings within package export data. Now the only remaining use is for Go source files, which allows for some substantial simplifications: 1. CenterDot never appears within Go source files, so that logic can simply be removed. 2. The field name will always be declared in the local package. Passes toolstash-check. Change-Id: I59505f62824206dd5de0782918f98fbef6e93224 Reviewed-on: https://go-review.googlesource.com/58790 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
griesemer authored
The enumeration of numeric types missed the complex types. Clarify by removing the explicit enumeration and referring to numeric types instead. Fixes #21579. Change-Id: If36c2421f8501eeec82a07f442ac2e16a35927ba Reviewed-on: https://go-review.googlesource.com/58491Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Matthew Dempsky authored
Discovered while debugging CL 53644. No test case because these are purely internal conversions that should never end up resulting in compiler warnings or even generated code. Updates #19683. Change-Id: I0d9333ef2c963fa22eb9b5335bb022bcc9b25708 Reviewed-on: https://go-review.googlesource.com/58190 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
griesemer authored
The old wording seemed to imply that nil is a kind of type. Slightly reworded for clarity. Fixes #21580. Change-Id: I29898bf0125a10cb8dbb5c7e63ec5399ebc590ca Reviewed-on: https://go-review.googlesource.com/58490Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Rob Pike <r@golang.org>
-
Keith Randall authored
When we remove a nil check, add it back to the free Value pool immediately. Fixes #18732 Change-Id: I8d644faabbfb52157d3f2d071150ff0342ac28dc Reviewed-on: https://go-review.googlesource.com/58810 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Tom Levy authored
There are some major problems with TestAdversary (based on "A Killer Adversary for Quicksort"[1] by M. D. McIlroy). See #21581 for details. Rewrite the test to closely match the version in the paper so it can be verified as correct by virtue of similarity. The only major difference between this new version and the version in the paper is that this version swaps the values directly instead of permuting an array of indices because we don't need to recover the original permutation. This new version also counts the number of calls to Less() and fails the test if there are too many. Fixes #21581. [1]: http://www.cs.dartmouth.edu/~doug/mdmspe.pdf Change-Id: Ia94b5b6d288b8fa3805a5fa27661cebbc5bad9a7 Reviewed-on: https://go-review.googlesource.com/58330 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Tom Levy authored
The tests were removed in https://golang.org/cl/2311 but some references to them were missed. Change-Id: I163e554a0cc99401a012deead8fda813ad74dbfe Reviewed-on: https://go-review.googlesource.com/58870Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David du Colombier authored
CL 54410 and CL 56250 recently added use of the MOVOstore instruction to improve performance. However, we can't use the MOVOstore instruction on Plan 9, because floating point operations are not allowed in the note handler. This change adds a configuration flag useSSE to enable the use of SSE instructions for non-floating point operations. This flag is enabled by default and disabled on Plan 9. When this flag is disabled, the MOVOstore instruction is not used and the MOVQstoreconst instruction is used instead. Fixes #21599 Change-Id: Ie609e5d9b82ec0092ae874bab4ce01caa5bc8fb8 Reviewed-on: https://go-review.googlesource.com/58850Reviewed-by: Keith Randall <khr@golang.org>
-
Wei Congrui authored
This change also added the same check in make.bash to make.rc, which makes sure $GOROOT_BOOTSTRAP != $GOROOT. Fixes #14339 Change-Id: I2758f4a845bae42ace02492fc6a911f6d6247d26 Reviewed-on: https://go-review.googlesource.com/57753 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Joe Tsai authored
WriteHeader may fail to encode a header for any number of reasons, which can be frustrating for the user when trying to create a tar archive. As we validate the Header, we generate an informative error message intended for human consumption and return that if and only if no format can be selected. This allows WriteHeader to return informative errors like: tar: cannot encode header: invalid PAX record: "linkpath = \x00hello" tar: cannot encode header: invalid PAX record: "SCHILY.xattr.foo=bar = baz" tar: cannot encode header: Format specifies GNU; and only PAX supports Xattrs tar: cannot encode header: Format specifies GNU; and GNU cannot encode ModTime=1969-12-31 15:59:59.0000005 -0800 PST tar: cannot encode header: Format specifies GNU; and GNU supports sparse files only with TypeGNUSparse tar: cannot encode header: Format specifies USTAR; and USTAR cannot encode ModTime=292277026596-12-04 07:30:07 -0800 PST tar: cannot encode header: Format specifies USTAR; and USTAR does not support sparse files tar: cannot encode header: Format specifies PAX; and only GNU supports TypeGNUSparse Updates #18710 Change-Id: I82a498d6f29d02c4e73bce47b768eb578da8499c Reviewed-on: https://go-review.googlesource.com/58310 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-