Converting a syscall.Errno to an interface is
a significant source of allocations in os/exec.
Elsewhere in the tree, we have pre-allocated errors
for common errno values. Use the same trick here.
This CL makes yet another copy of this code.
The problem is that there isn't really a great place to share it.
The existing copies are in:
cmd/vendor/golang.org/x/sys/unix
cmd/vendor/golang.org/x/sys/windows
cmd/vendor/golang.org/x/sys/windows/registry
internal/syscall/windows
internal/syscall/windows/registry
syscall
internal/poll can't import from cmd/vendor, and cmd/vendor
can't import from internal/*, so we can ignore cmd/vendor.
We could put the unix version in internal/syscall/unix
and then have a platform-independent wrapper in internal/syscall.
But syscall couldn't use it; internal/syscall/* depends on syscall.
So that only allows code re-use with internal/syscall/windows/*.
We could create a new very low level internal package, internal/errno.
But syscall couldn't use it, because it has to import syscall
to get access to syscall.Errno.
So that only allows code re-use with internal/syscall/windows/*.
It's not clear that that any of these options pulls its weight.
The obvious and "correct" place for this is syscall.
But we can't export syscall's version, because package syscall is frozen.
So just copy the code. There's not much of it.
name old alloc/op new alloc/op delta
ExecHostname-8 6.15kB ± 0% 6.13kB ± 0% -0.38% (p=0.000 n=20+19)
name old allocs/op new allocs/op delta
ExecHostname-8 34.0 ± 0% 31.0 ± 0% -8.82% (p=0.000 n=20+20)
Fixes#30535
Change-Id: Idd31c7cced6e15387acc698ffc011e1b7b479903
Reviewed-on: https://go-review.googlesource.com/c/164971
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The names of some instructions have been updated in the WebAssembly
specification to be more consistent, see
994591e51c.
This change to the spec is possible because it is still in a draft
state.
Go's support for WebAssembly is still experimental and thus excempt from
the compatibility promise. Being consistent with the spec should
warrant this breaking change to the assembly instruction names.
Change-Id: Iafb8b18ee7f55dd0e23c6c7824aa1fad43117ef1
Reviewed-on: https://go-review.googlesource.com/c/153797
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Most notably, it's missing on Windows machines. For example,
windows-amd64-race started failing consistently:
--- FAIL: BenchmarkExecEcho
bench_test.go:15: could not find echo: exec: "echo": executable file not found in %PATH%
We can also reproduce this from Linux with Wine:
$ GOOS=windows go test -bench=. -benchtime=1x -run=- -exec wine
--- FAIL: BenchmarkExecEcho
bench_test.go:15: could not find echo: exec: "echo": executable file not found in %PATH%
Instead, use the "hostname" program, which is available on Windows too.
Interestingly enough, it's also slightly faster than "echo". Any program
is fine as long as it's close enough to a no-op, though.
name old time/op new time/op delta
ExecEcho-8 422µs ± 0% 395µs ± 0% -6.39% (p=0.004 n=6+5)
name old alloc/op new alloc/op delta
ExecEcho-8 6.39kB ± 0% 6.42kB ± 0% +0.53% (p=0.002 n=6+6)
name old allocs/op new allocs/op delta
ExecEcho-8 36.0 ± 0% 36.0 ± 0% ~ (all equal)
Change-Id: I772864d69979172b5cf807552c84d0e165e73051
Reviewed-on: https://go-review.googlesource.com/c/164704
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change adds support for using wasm with Electron. It refactors
environment detection to a more modular approach instead of explicitly
testing for Node.js.
Fixes#29404
Change-Id: I882a9c56523744e7fd7cb2013d158df91cf91d14
Reviewed-on: https://go-review.googlesource.com/c/164665
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There's a "lib/time" sub-section in the Go 1.12 relase notes that
points to a non-existent golang.org/pkg/lib/time page.
The note is about a change in the tz database in the src/lib/time
directory, but the section's title (and the link) should probably just
refer to the time package.
Change-Id: Ibf9dacd710e72886f14ad0b7415fea1e8d25b83a
Reviewed-on: https://go-review.googlesource.com/c/164977
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We're always going to add stdin, stdout, and stderr to childFiles, so
its length will be at least three. The final length will be those three
elements plus however many files were given via ExtraFiles.
Allocate for that final length directly, saving two slice growth allocs
in the common case where ExtraFiles is empty.
name old time/op new time/op delta
ExecEcho-8 435µs ± 0% 435µs ± 0% ~ (p=0.394 n=6+6)
name old alloc/op new alloc/op delta
ExecEcho-8 6.39kB ± 0% 6.37kB ± 0% -0.39% (p=0.002 n=6+6)
name old allocs/op new allocs/op delta
ExecEcho-8 36.0 ± 0% 34.0 ± 0% -5.56% (p=0.002 n=6+6)
Change-Id: Ib702c0da1e43f0a55ed937af6d45fca6a170e8f3
Reviewed-on: https://go-review.googlesource.com/c/164898
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Most of the encoding time is spent in the first Encode loop, since the
rest of the function only deals with the few remaining bytes. Any
unnecessary work done in that loop body matters tremendously.
One such unnecessary bottleneck was the use of the enc.encode table.
Since enc is a pointer receiver, and the field is first used within the
loop, the encoder must perform a nil check at every iteration.
Add a dummy use of the field before the start of the loop, to move the
nil check there. After that line, the compiler now knows that enc can't
be nil, and thus the hot loop is free of nil checks.
name old time/op new time/op delta
EncodeToString-4 14.7µs ± 0% 13.7µs ± 1% -6.53% (p=0.000 n=10+10)
name old speed new speed delta
EncodeToString-4 559MB/s ± 0% 598MB/s ± 1% +6.99% (p=0.000 n=10+10)
Updates #20206.
Change-Id: Icbb523a7bd9e470a8be0a448d1d78ade97ed4ff6
Reviewed-on: https://go-review.googlesource.com/c/151158
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
According to
https://stackoverflow.com/questions/46233200/stop-buffering-of-adb-shell-output
the adb exec-out commands avoids the buffering inherent to adb shell.
Let's see if using exec-out will fix the android builder flakyness where
exitcodes or output were sometimes missing.
Updates #30512 (perhaps fixes it).
Change-Id: Ib953ef0262b20730e0d4c332058d29c5066bfeb2
Reviewed-on: https://go-review.googlesource.com/c/164661
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
encoding/base64 already skips \r and \n when decoding, so this package
must only deal with spaces and tabs. Those aren't nearly as common, so
we can add a fast path with bytes.ContainsAny to skip the costly alloc
and filtering code.
name old time/op new time/op delta
Decode-8 279µs ± 0% 259µs ± 1% -7.07% (p=0.002 n=6+6)
name old speed new speed delta
Decode-8 319MB/s ± 0% 343MB/s ± 1% +7.61% (p=0.002 n=6+6)
name old alloc/op new alloc/op delta
Decode-8 164kB ± 0% 74kB ± 0% -54.90% (p=0.002 n=6+6)
name old allocs/op new allocs/op delta
Decode-8 12.0 ± 0% 11.0 ± 0% -8.33% (p=0.002 n=6+6)
Change-Id: Idfca8700c52f46eb70a4a7e0d2db3bf0124e4699
Reviewed-on: https://go-review.googlesource.com/c/155964
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Instead of allocating a byte slice for every string,
calculated the required size and create
a single slice big enough to hold all of them.
As an added benefit, any error encountered
will now be returned before allocations occur.
os/exec package benchmarks:
name old time/op new time/op delta
ExecEcho-8 2.14ms ± 1% 2.14ms ± 3% ~ (p=0.842 n=10+9)
name old alloc/op new alloc/op delta
ExecEcho-8 6.35kB ± 0% 6.18kB ± 0% -2.65% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
ExecEcho-8 69.0 ± 0% 36.0 ± 0% -47.83% (p=0.000 n=10+10)
Change-Id: I84118d8473037d873f73903d4e4f6ed14f531ce7
Reviewed-on: https://go-review.googlesource.com/c/164961
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The common case is that most env vars are distinct;
optimize for that.
name old time/op new time/op delta
ExecEcho-8 2.16ms ± 3% 2.14ms ± 1% ~ (p=0.315 n=10+10)
name old alloc/op new alloc/op delta
ExecEcho-8 7.87kB ± 0% 6.35kB ± 0% -19.31% (p=0.000 n=9+10)
name old allocs/op new allocs/op delta
ExecEcho-8 72.0 ± 0% 69.0 ± 0% -4.17% (p=0.000 n=10+10)
Change-Id: I42bb696c6862f2ea12c5cbd2f24c64336a7a759a
Reviewed-on: https://go-review.googlesource.com/c/164960
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
gogrep found only one such case with the pattern below:
$tmp := $x; $x = $y; $y = $tmp
R=1.13
Change-Id: I6e46fb5ef2887f24fa9fc451323a8cef272e2886
Reviewed-on: https://go-review.googlesource.com/c/151200
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
We were using t.Parallel in a subtest, which meant that the main test
would not wait for the subtest, so the main test would delete the
temporary directory before the subtest used it. The subtest worked
because "go build -o /tmp/x/y/p.exe p" creates /tmp/x/y as needed.
Updates #30500
Change-Id: I5904ecac748d15ded4cb609f049fa548b8916a0e
Reviewed-on: https://go-review.googlesource.com/c/164857
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The variable err could have nil value when we call err.Error(),
because after we check it for nil above we continue the test
(t.Errorf doesn't stop the test execution).
Updates #30208
Change-Id: I6f7a8609f2453f622a1fa94a50c99d2e04d5fbcd
GitHub-Last-Rev: 3a5d9b1e9e
GitHub-Pull-Request: golang/go#30215
Reviewed-on: https://go-review.googlesource.com/c/162477
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
replaces broken link with a web.archive.org link.
Change-Id: I438536a6ac51d837c30be5df7d3d0caadf65bb95
GitHub-Last-Rev: 0601e4d6b2
GitHub-Pull-Request: golang/go#30523
Reviewed-on: https://go-review.googlesource.com/c/164761
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The change makes it easier for a user to get to the page where
she can check supported test flags, by adding 'go test testflag'
reference to the 'go test -help' output.
Fix#30365
Change-Id: I5b3db7853021ef68d096dcb467d7957d7e1bf623
GitHub-Last-Rev: ce3dec59fc
GitHub-Pull-Request: golang/go#30420
Reviewed-on: https://go-review.googlesource.com/c/163858
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We were accidentally ignoring any error returned by poll.SendFile.
Noticed by reading the code. It could only change behavior if the
sendfile system call both wrote some bytes and returned an error.
Change-Id: I0693d6ec0a30f5a86b78d38793899ca29fb9e156
Reviewed-on: https://go-review.googlesource.com/c/164760
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Split TestMain into two functions so that we can defer cleanups.
Updates #30500
Change-Id: I4a5c7ddb8218a8bd056c8733c3cb9feb895e77a0
Reviewed-on: https://go-review.googlesource.com/c/164859
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
The deferred os.RemoveAll was accidentally committed as commented out
in the original https://golang.org/cl/87158.
Updates #30500
Change-Id: Idc5195816d7978253760dbfd78fde6d22c456296
Reviewed-on: https://go-review.googlesource.com/c/164858
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Split TestMain into two functions so that we can defer cleanups.
Updates #30500
Change-Id: I1fa7957be0779c079ec4d221a8321b45ddb973e2
Reviewed-on: https://go-review.googlesource.com/c/164860
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
We mostly use shell variables for paths, and we don't want file paths
like "C:\work\go1.4" to turn into regular expressions.
Updates #30228
Updates #30241
Change-Id: If18b775b2f8b2821eaf197c4be4a322066af839f
Reviewed-on: https://go-review.googlesource.com/c/164626
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Android now works with all.bash.
Change-Id: I1087308865d2eb31f02501b5798e14d11145b185
Reviewed-on: https://go-review.googlesource.com/c/164700
Run-TryBot: Elias Naur <mail@eliasnaur.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
That makes the test more friendly to the Android exec script, since it
won't have to evaluate symlinks to find the directory.
Change-Id: I06aae3224d489eed6d7fac7e462361f3bf1dd3da
Reviewed-on: https://go-review.googlesource.com/c/164624
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Elias Naur <mail@eliasnaur.com>
Ensure that cmd/go consistently calls base.Exit rather than os.Exit,
so that we don't incorrectly leave the work directory around on exit.
Test this by modifying the testsuite to run all the tests with TMPDIR
set to a temporary directory, and then check that no files are left
behind in that temporary directory. Adjust a couple of tests to make
this approach work.
Updates #30500
Updates https://gcc.gnu.org/PR89406
Change-Id: Ib6a5fc8a288a6cf4713022baa2b8dfefad62ba34
Reviewed-on: https://go-review.googlesource.com/c/163237
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Otherwise, if the working directory is inside a standard-library
module, the test may try to fetch module contents from GOPROXY or
upstream.
Updates #26924
Updates #30228
Updates #30241
Change-Id: I4cb9a07721bd808fd094f7ed55a74cf7bce9cd6f
Reviewed-on: https://go-review.googlesource.com/c/164625
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Previous CLs added symlink evaulation to GOROOT and GOPATH.
Unfortunately that only fixed tests that ran outside GOROOT.
To fix the standard library tests, evaluate symlinks in the current
working directory as well.
Change-Id: Ia406a968235ae4321a1002567520105998582d15
Reviewed-on: https://go-review.googlesource.com/c/164699
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
These tests check for GOPATH-mode vendoring behavior, so make sure
they're in GOPATH mode.
Updates #30228
Change-Id: I646f59b67cb76dacd07adc3f6ed15ed63f4e22a4
Reviewed-on: https://go-review.googlesource.com/c/164620
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
With stack objects, when we scan the stack, it scans defers with
tracebackdefers, but it seems to me that tracebackdefers doesn't
include the func value itself, which could be a stack allocated
closure. Scan it explicitly.
Alternatively, we can change tracebackdefers to include the func
value, which in turn needs to change the type of stkframe.
Fixes#30453.
Change-Id: I55a6e43264d6952ab2fa5c638bebb89fdc410e2b
Reviewed-on: https://go-review.googlesource.com/c/164118
Reviewed-by: Keith Randall <khr@golang.org>
Currently, runtime.KeepAlive applied on a stack object doesn't
actually keeps the stack object alive, and the heap object
referenced from it could be collected. This is because the
address of the stack object is rematerializeable, and we just
ignored KeepAlive on rematerializeable values. This CL fixes it.
Fixes#30476.
Change-Id: Ic1f75ee54ed94ea79bd46a8ddcd9e81d01556d1d
Reviewed-on: https://go-review.googlesource.com/c/164537
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
