- 20 May, 2019 2 commits
-
-
taoyuanyuan authored
The chunks that were referenced by fd.iovecs would not be GC. Change-Id: I7bfcb91a3fef57a4a1861168e9cd3ab55ce1334e GitHub-Last-Rev: e0b7f68447441fd89ed1a6e8aa37e2084fd863b2 GitHub-Pull-Request: golang/go#32138 Reviewed-on: https://go-review.googlesource.com/c/go/+/178037 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
smasher164 authored
Make the extended precision add-with-carry and sub-with-carry operations take a constant amount of time to execute, regardless of input. name old time/op new time/op delta Add-4 1.16ns ±11% 1.51ns ± 5% +30.52% (p=0.008 n=5+5) Add32-4 1.08ns ± 0% 1.03ns ± 1% -4.86% (p=0.029 n=4+4) Add64-4 1.09ns ± 1% 1.95ns ± 3% +79.23% (p=0.008 n=5+5) Add64multiple-4 4.03ns ± 1% 4.55ns ±11% +13.07% (p=0.008 n=5+5) Sub-4 1.08ns ± 1% 1.50ns ± 0% +38.17% (p=0.016 n=5+4) Sub32-4 1.09ns ± 2% 1.53ns ±10% +40.26% (p=0.008 n=5+5) Sub64-4 1.10ns ± 1% 1.47ns ± 1% +33.39% (p=0.008 n=5+5) Sub64multiple-4 4.30ns ± 2% 4.08ns ± 4% -5.07% (p=0.032 n=5+5) Fixes #31267 Change-Id: I1824b1b3ab8f09902ce8b5fef84ce2fdb8847ed9 Reviewed-on: https://go-review.googlesource.com/c/go/+/170758Reviewed-by:
Filippo Valsorda <filippo@golang.org> Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 17 May, 2019 12 commits
-
-
Keith Randall authored
callerName requested 2 PCs from Callers, and that causes both to be looked up in the file/line mapping. We really only need to do the work for one PC. (And in fact the caller doesn't need file/line at all, but the Callers API can't express that.) We used to request 2 PCs because in 1.11 and earlier we stored an inline skip count in the second entry. That's not necessary any more (as of 1.12). Fixes #32093 Change-Id: I7b272626ef6496e848ee8af388cdaafd2556857b Reviewed-on: https://go-review.googlesource.com/c/go/+/177858 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Caleb Spare <cespare@gmail.com>
-
Josh Bleecher Snyder authored
name old alloc/op new alloc/op delta Template 37.1MB ± 0% 36.8MB ± 0% -0.57% (p=0.008 n=5+5) Unicode 28.1MB ± 0% 28.1MB ± 0% -0.07% (p=0.008 n=5+5) GoTypes 125MB ± 0% 124MB ± 0% -0.61% (p=0.008 n=5+5) Compiler 571MB ± 0% 568MB ± 0% -0.60% (p=0.008 n=5+5) SSA 1.88GB ± 0% 1.86GB ± 0% -0.82% (p=0.008 n=5+5) Flate 22.9MB ± 0% 22.8MB ± 0% -0.59% (p=0.008 n=5+5) GoParser 27.5MB ± 0% 27.3MB ± 0% -0.53% (p=0.008 n=5+5) Reflect 79.8MB ± 0% 79.5MB ± 0% -0.40% (p=0.008 n=5+5) Tar 34.9MB ± 0% 34.7MB ± 0% -0.44% (p=0.008 n=5+5) XML 45.7MB ± 0% 45.4MB ± 0% -0.58% (p=0.008 n=5+5) [Geo mean] 80.3MB 79.9MB -0.52% name old allocs/op new allocs/op delta Template 380k ± 0% 378k ± 0% -0.57% (p=0.008 n=5+5) Unicode 340k ± 0% 340k ± 0% -0.08% (p=0.008 n=5+5) GoTypes 1.36M ± 0% 1.36M ± 0% -0.44% (p=0.008 n=5+5) Compiler 5.52M ± 0% 5.49M ± 0% -0.45% (p=0.008 n=5+5) SSA 17.6M ± 0% 17.5M ± 0% -0.42% (p=0.008 n=5+5) Flate 235k ± 0% 234k ± 0% -0.65% (p=0.008 n=5+5) GoParser 302k ± 0% 300k ± 0% -0.70% (p=0.008 n=5+5) Reflect 982k ± 0% 978k ± 0% -0.40% (p=0.008 n=5+5) Tar 353k ± 0% 351k ± 0% -0.53% (p=0.008 n=5+5) XML 437k ± 0% 435k ± 0% -0.48% (p=0.008 n=5+5) [Geo mean] 844k 840k -0.47% Updates #27739 Change-Id: I5d533013270cbbd7c0bad1b43da96c8499be76f5 Reviewed-on: https://go-review.googlesource.com/c/go/+/177917 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Filippo Valsorda authored
In TLS 1.3 session tickets are delivered after the handshake, and it looks like now the Google servers wait until the first flight of data to send them (or our timeout is too low). Cause some data to be sent so we can avoid the guessing game. Fixes #32090 Change-Id: I54af4acb3a89cc70c9e14a5dfe18a44c29a841a7 Reviewed-on: https://go-review.googlesource.com/c/go/+/177877Reviewed-by:
-
Dmitri Shuralyov authored
The motivation for doing so is to avoid making inaccurate claims. Logging may not go to os.Stderr if anyone overrides the log package's default output via https://godoc.org/log#SetOutput. Saying that the standard logger is used should be sufficient to explain the behavior, and users can infer that os.Stderr is used by default, unless it's changed. This change is the same as what was applied to http.Server.ErrorLog documentation in CL 53950. Change-Id: I32873fc548ceee573f8616b4d49b8a8b98881803 Reviewed-on: https://go-review.googlesource.com/c/go/+/176817Reviewed-by:
-
Jay Conrod authored
When we downgrade a module (using 'go get m@none' or similar), we exclude versions of other modules that depend on it. We'll try previous versions (in the "versions" list returned by the proxy or in codeRepo.Versions for vcs) until we find a version that doesn't require an excluded module version. If older versions of a module are broken for some reason, mvs.Downgrade currently panics. With this change, we ignore versions with errors during downgrade. A frequent cause of this is incompatible v2+ versions. These are common if a repository tagged v2.0.0 before migrating to modules, then tagged v2.0.1 with a go.mod file later. v2.0.0 is incorrectly considered part of the v2 module. Fixes #31942 Change-Id: Icaa75c5c93f73f18a400c22f18a8cc603aa4011a Reviewed-on: https://go-review.googlesource.com/c/go/+/177337 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Bryan C. Mills <bcmills@google.com>
-
Jean de Klerk authored
The current example illustrates using As when the error is able to be interpreted as an os.PathError, but elides the "else" case. This CL adds the small extra else case to make it clear that it's not safe to assume As will return true. This CL also squash the err instantiation and the err nil check into one line for brevity. Change-Id: I3d3ab483ffb38fb2788d0498b3f03229a87dd7c3 Reviewed-on: https://go-review.googlesource.com/c/go/+/177717Reviewed-by:
Jonathan Amsterdam <jba@google.com> Reviewed-by:
Damien Neil <dneil@google.com> Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Filippo Valsorda authored
Support for Ed25519 certificates was added in CL 175478, this wires them up into the TLS stack according to RFC 8422 (TLS 1.2) and RFC 8446 (TLS 1.3). RFC 8422 also specifies support for TLS 1.0 and 1.1, and I initially implemented that, but even OpenSSL doesn't take the complexity, so I just dropped it. It would have required keeping a buffer of the handshake transcript in order to do the direct Ed25519 signatures. We effectively need to support TLS 1.2 because it shares ClientHello signature algorithms with TLS 1.3. While at it, reordered the advertised signature algorithms in the rough order we would want to use them, also based on what curves have fast constant-time implementations. Client and client auth tests changed because of the change in advertised signature algorithms in ClientHello and CertificateRequest. Fixes #25355 Change-Id: I9fdd839afde4fd6b13fcbc5cc7017fd8c35085ee Reviewed-on: https://go-review.googlesource.com/c/go/+/177698 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Adam Langley <agl@golang.org>
-
Joel Sing authored
A timespec on netbsd/amd64 is int64/int64, not int64/int32. This bug appears to have been introduced in 7777bac6. Spotted by Cherry Zhang while reviewing https://go-review.googlesource.com/c/go/+/177120. Change-Id: I163c55d926965defd981bdbfd2511de7d9d4c542 Reviewed-on: https://go-review.googlesource.com/c/go/+/177637Reviewed-by:
Benny Siegert <bsiegert@gmail.com> Reviewed-by:
Cherry Zhang <cherryyz@google.com> Run-TryBot: Benny Siegert <bsiegert@gmail.com>
-
Joel Sing authored
Fix various bugs in the netbsd/arm64 runtime assembly. Updates #30824. Change-Id: I5ca10926ab663a8ff4df9973530e645e2469c1aa Reviewed-on: https://go-review.googlesource.com/c/go/+/177120Reviewed-by:
-
Ben Shi authored
A cross C compiler should be specified when cross building go for android on x86 host. This CL fixes the typo in README. Change-Id: Ideda915364d9f7f0fcd53146abc1e74506a8a8e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/177777Reviewed-by:
Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by:
Elias Naur <mail@eliasnaur.com>
-
Joey authored
Change-Id: I44af6cd8baa8fcd2a666429467fae4bed5f21fa0 GitHub-Last-Rev: d0c9722f082114b356de55fc79ce138ede019636 GitHub-Pull-Request: golang/go#32052 Reviewed-on: https://go-review.googlesource.com/c/go/+/177277Reviewed-by:
-
Keith Randall authored
Update #28603 Change-Id: I8bdbea57b3661e15dcc760d27252b794daa476db Reviewed-on: https://go-review.googlesource.com/c/go/+/177697Reviewed-by:
-
- 16 May, 2019 20 commits
-
-
Jay Conrod authored
If a user runs 'go get mod@vers' where the module transitively requires itself at a newer version, 'go get' attempts to perform a downgrade, which necessarily excludes the requested version of the module. Previously, we called mvs.BuildList with the requested module version as the target. This panicked because BuildList doesn't allow the target module (typically the main module) to require a newer version of itself. With this change, when we lose an upgrade due to a downgrade, we call mvs.BuildList through a wrapper that treats the lost module version as requirement of a synthetic root module, rather than the target module. This avoids the panic. This change also starts reporting errors when an upgraded module is lost entirely (downgrades caused the module to be completely removed from the build list). Fixes #31491 Change-Id: I70ca261c20af7553cad2d3b840a1eaf3d18a4191 Reviewed-on: https://go-review.googlesource.com/c/go/+/177602 Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by:
-
Michael Anthony Knyszek authored
On most platforms newly-mapped memory is untouched, meaning the pages backing the region haven't been faulted in yet. However, we mark this memory as unscavenged which means the background scavenger aggressively "returns" this memory to the OS if the heap is small. The only platform where newly-mapped memory is actually unscavenged (and counts toward the application's RSS) is on Windows, since (*mheap).sysAlloc commits the reservation. Instead of making a special case for Windows, I change the requirements a bit for a sysReserve'd region. It must now be both sysMap'd and sysUsed'd, with sysMap being a no-op on Windows. Comments about memory allocation have been updated to include a more up-to-date mental model of which states a region of memory may be in (at a very low level) and how to transition between these states. Now this means we can correctly mark newly-mapped heap memory as scavenged on every platform, reducing the load on the background scavenger early on in the application for small heaps. As a result, heap-growth scavenging is no longer necessary, since any actual RSS growth will be accounted for on the allocation codepath. Finally, this change also cleans up grow a little bit to avoid pretending that it's freeing an in-use span and just does the necessary operations directly. Fixes #32012. Fixes #31966. Updates #26473. Change-Id: Ie06061eb638162e0560cdeb0b8993d94cfb4d290 Reviewed-on: https://go-review.googlesource.com/c/go/+/177097 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Brad Fitzpatrick authored
For: http2: track reused connections https://golang.org/cl/176720 (updates golang/go#31982) Some x/sys/unix updates come along for the ride too. I filed #32031 for making the bundling process less difficult and error-prone in the future. Change-Id: Ic822080991ffa2d50352c5f613e45648a327cf16 Reviewed-on: https://go-review.googlesource.com/c/go/+/177037 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: -
Bryan C. Mills authored
Fixes #32060 Change-Id: I49ab48a9bdd64a7ed777a045e2d92d28a37b5c0b Reviewed-on: https://go-review.googlesource.com/c/go/+/177600 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Bryan C. Mills authored
Updates #30790 Fixes #31960 Change-Id: Ib3ac074cf1f98fe69f53af82d2a0441582116570 Reviewed-on: https://go-review.googlesource.com/c/go/+/176925 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by:
Jay Conrod <jayconrod@google.com>
-
Josh Bleecher Snyder authored
The compiler appears to have a latent bug: fusePlain calls invalidateCFG when it changes block structure, but fuseIf does not. Fix this by hoisting the call to invalidateCFG to the top level. Change-Id: Ic960fb3ac963b15b4a225aad84863d58efa954e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/177198 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
fanzha02 authored
The CL 164718 mistyped the comparison flags. The rules for floating point comparison should be GreaterThanF and GreaterEqualF. Fortunately, the wrong optimizations were overwritten by other integer rules, so the issue won't cause failure but just some performance impact. The fixed CL optimizes the floating point test as follows. source code: func foo(f float64) bool { return f > 4 || f < -4} previous version: "FCMPD", "CSET\tGT", "CBZ" fixed version: "FCMPD", BLE" Add the test case. Change-Id: Iea954fdbb8272b2d642dae0f816dc77286e6e1fa Reviewed-on: https://go-review.googlesource.com/c/go/+/177121Reviewed-by:Ben Shi <powerman1st@163.com> Reviewed-by:
-
Jason A. Donenfeld authored
This is CVE-2019-11888. Previously, passing a nil environment but a non-nil token would result in the new potentially unprivileged process inheriting the parent potentially privileged environment, or would result in the new potentially privileged process inheriting the parent potentially unprivileged environment. Either way, it's bad. In the former case, it's an infoleak. In the latter case, it's a possible EoP, since things like PATH could be overwritten. Not specifying an environment currently means, "use the existing environment". This commit amends the behavior to be, "use the existing environment of the token the process is being created for." The behavior therefore stays the same when creating processes without specifying a token. And it does the correct thing when creating processes when specifying a token. Fixes #32000 Change-Id: Ia57f6e89b97bdbaf7274d6a89c1d9948b6d40ef5 Reviewed-on: https://go-review.googlesource.com/c/go/+/176619 Run-TryBot: Jason Donenfeld <Jason@zx2c4.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Alex Brainman <alex.brainman@gmail.com>
-
David Chase authored
This is useful for debugging line number assignment and also for making sense of pathological line number inputs. Activated with -gcflags=-d=ssa/number_lines/stats=1 (the bit matters) -gcflags=-d=ssa/number_lines/debug Stats: "SUM_LINE_RANGE", SUM for f in files {MAX line in f {line}-MIN line in f {line}} "MAXMIN_LINE_RANGE", MAX for f in files {MAX line in f {line}} - MIN for f in files {MIN line in f {line}} "MAXFILE", maxfile, MAX for f in files {f} "NFILES", len(entries) | files | Change-Id: I8a7336e6370452fe2e3a62de17606db9bd6a6fd3 Reviewed-on: https://go-review.googlesource.com/c/go/+/174947 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Russ Cox authored
This cuts the time for 'go test -short testing' from 0.9s to < 0.1s. Change-Id: Ib8402f80239e1e96ea5221dfd5cd0db08170d85b Reviewed-on: https://go-review.googlesource.com/c/go/+/177420 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
CL 121936 added this diagnostic to avoid a panic accessing *short. (Hence the "This shouldn't really be a panic" comment.) That CL was right to produce a clearer error than a plain memory fault, but I think wrong to print+exit instead of panicking. I just ran into one of these in a real program, and there is no indication anywhere of how the program reached this point. The panic will show that. So change print+exit to a panic with a helpful message, in contrast to the original panic with an unhelpful message and the current helpful message without stack trace. Change-Id: Ib2bae1dead4ccde92f00fa3a34c05241ff7690c6 Reviewed-on: https://go-review.googlesource.com/c/go/+/177419 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
This just makes all.bash a bit less chatty. Change-Id: I7d2ecabf0c7d8df2065d7052718f611bb2907801 Reviewed-on: https://go-review.googlesource.com/c/go/+/177418 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
These tests take 20 seconds each to rebuild the entire world in their respective modes. That's too much for short mode, including all.bash on developer machines. Keep doing it on builders and if someone runs 'go test' by hand in that directory. For #26473. Change-Id: I3dc6955bc3aa7a20fd170efcde72a7d19b37bdbf Reviewed-on: https://go-review.googlesource.com/c/go/+/177417 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Speeds up the "go test runtime -cpu=1,2,4 -short -quick" phase of all.bash. For #26473. Change-Id: I090f5a5aa754462b3253a2156dc31fa67ce7af2a Reviewed-on: https://go-review.googlesource.com/c/go/+/177399 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Was 50 seconds on unloaded Mac laptop; now 27. Still longer than I would like, but every little bit helps. For #26473. Change-Id: Id4be016ee1555cbc3512eca0ae10236d7f06bd02 Reviewed-on: https://go-review.googlesource.com/c/go/+/177398 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
_go_testing is equally unlikely and much less concerning than testing_xxxxxxxxxxxx if it appears in an error message (as it does, for example, in https://storage.googleapis.com/go-build-log/0d543f89/linux-amd64_3467a10e.log). Change-Id: I45dc3ebe2d3b6c9e53273cd21782ee11a53f5edb Reviewed-on: https://go-review.googlesource.com/c/go/+/177197 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Add information about action and build IDs, commands run, time spent in commands, and overall time to -debug-actiongraph output. Also avoid a terrible outcome in: go build -debug-actiongraph x.go Change-Id: I7a3a638f4848d75f2bdc997517f4ab23656da4f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/177138 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
The work of running full vet on std and cmd during local development has moved to go test, which of course runs during all.bash. For errors in other GOOS/GOARCH combinations, the misc-compile builders (running buildall.bash) also now run go vet std cmd. The vetall builder need not do anything anymore. Make it a no-op until it can be retired, and remove cmd/vet/all and its special case in the go command. Fixes #31916. Change-Id: I8f30d184c382ea7c2c8f520e5618f680db633968 Reviewed-on: https://go-review.googlesource.com/c/go/+/176440 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Now that the main tree complies with 'go vet', enable all vet checks during 'go test' in the main tree. This helps surface helpful errors while developing, instead of having to wait for the misc-vet-vetall builder. During 'go test', the additional vet checks are essentially free: the vet invocations themselves take only 8 seconds total for the entire tree. Also update buildall.bash (used by the misc-compile builders) to run 'go vet std cmd' for each GOOS/GOARCH pair. This is not as free, since in general it can require recompiling packages with their tests included before invoking vet. (That compilation was going on anyway in the 'go test' case.) On my Mac laptop, ./buildall.bash freebsd used to take 68+16+17+18 = 119 seconds for make.bash and then the builds of the three freebsd architectures. Now it takes 68+16+23+17+23+18+24 = 189 seconds, 60% longer. Some of this is spent doing unnecessary cgo work. Still, this lets us shard the vet checks and match all.bash. Fixes #20119. For #31916. Change-Id: I6b0c40bac47708a688463c7fca12c0fc23ab2751 Reviewed-on: https://go-review.googlesource.com/c/go/+/176439 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
This updates the Go function declarations to match race_amd64.s. Change-Id: I2b541a6b335ce732f4c31652aa615240ce7bb1c3 Reviewed-on: https://go-review.googlesource.com/c/go/+/177397 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 15 May, 2019 6 commits
-
-
Damien Neil authored
When fmt.Errorf is provided with a %w verb with an error operand, return an error implementing an Unwrap method returning that operand. It is invalid to use %w with other formatting functions, to use %w multiple times in a format string, or to use %w with a non-error operand. When the Errorf format string contains an invalid use of %w, the returned error does not implement Unwrap. Change-Id: I534e20d3b163ab22c2b137b1c9095906dc243221 Reviewed-on: https://go-review.googlesource.com/c/go/+/176998Reviewed-by:
Marcel van Lohuizen <mpvl@golang.org>
-
Damien Neil authored
Reverts the following changes: https://go.googlesource.com/go/+/1f90d081391d4f5911960fd28d81d7ea5e554a8f https://go.googlesource.com/go/+/8bf18b56a47a98b9dd2fa03beb358312237a8c76 https://go.googlesource.com/go/+/5402854c3557f87fa2741a52ffc15dfb1ef333cc https://go.googlesource.com/go/+/37f84817247d3b8e687a701ccb0d6bc7ffe3cb78 https://go.googlesource.com/go/+/6be6f114e0d483a233101a67c9644cd72bd3ae7a Partially reverts the followinng change, removing the errors.Opaque function and the errors.Wrapper type definition: https://go.googlesource.com/go/+/62f5e8156ef56fa61e6af56f4ccc633bde1a9120 Updates documentation referencing the Wrapper type. Change-Id: Ia622883e39cafb06809853e3fd90b21441124534 Reviewed-on: https://go-review.googlesource.com/c/go/+/176997 Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Filippo Valsorda authored
Based on RFC 8410. Updates #25355 Change-Id: If7abb7eeb0ede10a9bb3d2004f2116e587c6207a Reviewed-on: https://go-review.googlesource.com/c/go/+/175478 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Joel Sing authored
This allows the use of CLONE_VFORK and CLONE_VM for fork/exec, preventing "fork/exec ...: cannot allocate memory" failures from occuring when attempting to execute commands from a Go process that has a large memory footprint. Additionally, this should reduce the latency of fork/exec on these platforms. The same problem was addressed on linux/amd64 via issue #5838. Updates #31936 Change-Id: I7ae0fbbeaa29cab944a49a11272a380d497eb2d0 Reviewed-on: https://go-review.googlesource.com/c/go/+/175697 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Vet needs export data for the imports of the package it is analyzing. Vet does not need export data for the package itself, since vet will do its own type checking. Assuming that vet is just as good as the compiler at detecting invalid programs, don't run the compiler unnecessarily. This especially matters for tests without external test files or for which the external test files do not import the test-augmented original package. In that case, the test-augmented original package need not be compiled at all. Cuts time for 'go clean -cache && go vet -x cmd/compile/internal/ssa' from 7.6r 24.3u 2.8s to 3.5r 8.5u 1.9s, by not running the compiler on the augmented test package. There is still more to be done here - if we do need to build a test-augmented package, we rerun cgo unnecessarily. But this is a big help. Cuts time for 'go vet std cmd' by about 30%. For #31916. Change-Id: If6136b4d384f1da77aed90b43f1a6b95f09b5d86 Reviewed-on: https://go-review.googlesource.com/c/go/+/176438 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
Picks up vet fix from CL 176357. Change-Id: Ia77cd4a582c4edfbe59bbc311e6ce14046df0e83 Reviewed-on: https://go-review.googlesource.com/c/go/+/177137 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
