When the test retried multiple times, it reused the same Work variable,
causing in the builders being flaky due to panics. I was able to
immediately reproduce the failure with stress and -race:
$ go test -race -c && stress -p 32 ./par.test -test.run=TestWorkParallel$
/tmp/go-stress909062277
--- FAIL: TestWorkParallel (0.07s)
panic: par.Work.Do: already called Do [recovered]
panic: par.Work.Do: already called Do
Instead, use a new Work variable at each retry. Now, the line above
seems to never fail. Of course, much higher 'stress -p' values will
still result in "does not seem to be parallel" test failures since the
machine lacks resources. But those are test failures, not panics.
Fixes#26642.
Change-Id: I5e962eca7602cf413d911ff5669f56d4f52da5a7
Reviewed-on: https://go-review.googlesource.com/126355
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This variable is not used anymore. It was used in the
TestPackageNotStaleWithTrailingSlash test.
Change-Id: I5e52d4d1d91592dd21e2d9cff96974a49d07f5f8
Reviewed-on: https://go-review.googlesource.com/126376
Run-TryBot: Yury Smolsky <yury@smolsky.by>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change the Pipe() function to use the pipe() syscall (which has a unique
calling convention on linux/mips) instead of using pipe2(). This allows
it work on kernels <2.6.27 when pipe2() was introduced.
Change-Id: I65dfbd2a02b64e777a8eb13013d718e356521be6
GitHub-Last-Rev: c483a06168
GitHub-Pull-Request: golang/go#26608
Reviewed-on: https://go-review.googlesource.com/125915
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Vladimir Stefanovic <vladimir.stefanovic@mips.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing implementation of TLS connection has a deadlock. It occurs
when client connects to TLS server and doesn't send data for
handshake, so server calls Close on this connection. This is because
server reads data under locked mutex, while Close method tries to
lock the same mutex.
Fixes#23518
Change-Id: I4fb0a2a770f3d911036bfd9a7da7cc41c1b27e19
Reviewed-on: https://go-review.googlesource.com/90155
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Before this CL the user effectively has to guess at the expected
location of a binary-only package. While the location is normally
obvious ($GOPATH/pkg/GOOS_GOARCH/PATH/PKG.a) it is much less so when
building with options that implicitly add an -installsufix option.
Fixes#26590
Change-Id: I753ef54d6dcf733bb456dba65a4a92e4db57a1b0
Reviewed-on: https://go-review.googlesource.com/125818
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This avoids problems when running under QEMU. It seems that at least
some QEMU versions turn the sigaction implementation into a call to
the C library sigaction function. The C library function will reject
attempts to set the signal handler for signals 32 and 33. Ignore
errors in that case.
Change-Id: Id443a9a32f6fb0ceef5c59a398e7ede30bf71646
Reviewed-on: https://go-review.googlesource.com/125955
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The DNS client in net is documented to treat Conns returned by
Resolver.Dial which implement PacketConn as UDP and those which don't as
TCP regardless of what was requested. golang.org/cl/37879 changed the
DNS client to assume that the Conn returned by Resolver.Dial was the
requested type which broke compatibility.
Fixes#26573
Updates #16218
Change-Id: Idf4f073a4cc3b1db36a3804898df206907f9c43c
Reviewed-on: https://go-review.googlesource.com/125735
Run-TryBot: Ian Gudger <igudger@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The only inaccurate part was the HTTP/2 caveat in Server.ServeTLS, which
only applies to the plain Serve variant.
The restriction implemented in shouldConfigureHTTP2ForServe is not on
the setupHTTP2_ServeTLS codepath because ServeTLS owns the tls.Listener,
so we fix it for the user instead of disabling HTTP/2.
Fixes#24607
Change-Id: Ie5f207d0201f09db27bf81b75535e5f6fdaf91e2
Reviewed-on: https://go-review.googlesource.com/103815
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If we're in a libc call and get a trap, don't try to traceback the libc call.
Start from the state we had at entry to libc.
If there are multiple libc calls outstanding, remember the outermost one.
Fixes#26393
Change-Id: Icfe8794b95bf3bfd1a0679b456dcde2481dcabf3
Reviewed-on: https://go-review.googlesource.com/124195
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If we're compiling a large function, be more picky about how big
the function we're inlining is. If the function is >5000 nodes,
we lower the inlining threshold from a cost of 80 to 20.
Turns out reflect.Value's cost is exactly 80. That's the function
at issue in #26546.
20 was chosen as a proxy for "inlined body is smaller than the call would be".
Simple functions still get inlined, like this one at cost 7:
func ifaceIndir(t *rtype) bool {
return t.kind&kindDirectIface == 0
}
5000 nodes was chosen as the big function size. Here are all the
5000+ node (~~1000+ lines) functions in the stdlib:
5187 cmd/internal/obj/arm (*ctxt5).asmout
6879 cmd/internal/obj/s390x (*ctxtz).asmout
6567 cmd/internal/obj/ppc64 (*ctxt9).asmout
9643 cmd/internal/obj/arm64 (*ctxt7).asmout
5042 cmd/internal/obj/x86 (*AsmBuf).doasm
8768 cmd/compile/internal/ssa rewriteBlockAMD64
8878 cmd/compile/internal/ssa rewriteBlockARM
8344 cmd/compile/internal/ssa rewriteValueARM64_OpARM64OR_20
7916 cmd/compile/internal/ssa rewriteValueARM64_OpARM64OR_30
5427 cmd/compile/internal/ssa rewriteBlockARM64
5126 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_50
6152 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_60
6412 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_70
6486 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_80
6534 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_90
6534 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_100
6534 cmd/compile/internal/ssa rewriteValuePPC64_OpPPC64OR_110
6675 cmd/compile/internal/gc typecheck1
5433 cmd/compile/internal/gc walkexpr
14070 cmd/vendor/golang.org/x/arch/arm64/arm64asm decodeArg
There are a lot more smaller (~1000 node) functions in the stdlib.
The function in #26546 has 12477 nodes.
At some point it might be nice to have a better heuristic for "inlined
body is smaller than the call", a non-cliff way to scale down the cost
as the function gets bigger, doing cheaper inlined calls first, etc.
All that can wait for another release. I'd like to do this CL for
1.11.
Fixes#26546
Update #17566
Change-Id: Idda13020e46ec2b28d79a17217f44b189f8139ac
Reviewed-on: https://go-review.googlesource.com/125516
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The old version git not support "--no-show-signature", git add this from
v2.10.0.
Fixesgolang/go#26501.
Change-Id: Ia6b54488651e8687b08a4d40e092822bf960c4fe
Reviewed-on: https://go-review.googlesource.com/125315
Run-TryBot: Baokun Lee <nototon@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
"string" should really be "struct" in the structures describing the module.
Change-Id: I4e9cb12434bd33aa243622380c78e5e297d01d0b
Reviewed-on: https://go-review.googlesource.com/125638
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
1. Connections and codecs need to be partially safe for concurrent use.
Namely, read side is serialized by one mutex,
and writing side is serialized by another.
Current comment says that they need to be fully thread-safe,
which makes the default implementations (gobClientCodec/gobServerCodec)
non-conforming.
2. Say that ServerCodec.Close can be called multiple times
and must be idempotent. Server requires this and gobServerCodec
accounts for this, but the requirement is not documented.
Change-Id: Ie877e37891fed28056e3d9d1722edaed8e154067
Reviewed-on: https://go-review.googlesource.com/120818
Reviewed-by: Rob Pike <r@golang.org>
There's a 50ms threshold in net/http.Transport that this test
sometimes hitting on slower devices. That was unrelated to what this
test was trying to test. So instead just t.Skip on RoundTrip errors
unless the failure was quick (under 25ms), in which case the error
must've been about something else. Our fast machines should catch
regressions there.
Fixes#25366
Change-Id: Ibe8e2716a5b68558b57d0b8b5c46f38e46a2cba2
Reviewed-on: https://go-review.googlesource.com/125555
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Contains portions and modified portions of CL 103815
Fixes#24607
Change-Id: Ic330850a0f098f183315f04ea4780eded46c5b77
Reviewed-on: https://go-review.googlesource.com/125515
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For unknown reasons, linking against CoreFoundation on macOS 10.10
sometimes causes mmap to ignore the hint address, which makes the Go
allocator incompatible with TSAN. Currently, the effect of this is to
run the allocator out of arena hints on the very first allocation,
causing a "too many address space collisions for -race mode" panic.
This CL skips the cgo tests that link against CoreFoundation in race
mode.
Updates #26475.
Updates #26513.
Change-Id: I52ec638c99acf5d4966e68ff0054f7679680dac6
Reviewed-on: https://go-review.googlesource.com/125304
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Gccgo produced incorrect order of evaluation for expressions
involving &&, || subexpressions. The fix is CL 125299.
Updates #26495.
Change-Id: I18d873281709f3160b3e09f0b2e46f5c120e1cab
Reviewed-on: https://go-review.googlesource.com/125301
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Add the tools section with a Gofmt sub-section, just like in
go1.10.html. Instead of copying the two last paragraphs from 1.10, which
warn users about the hidden complexity of enforcing gofmt, move that to
go/format and link to it.
While at it, remove a duplicate "Tools" header that was likely added by
accident.
Fixes#26228.
Change-Id: Ic511c44b2b86f82a41f2b78dd7e7482d694b6c62
Reviewed-on: https://go-review.googlesource.com/122295
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The doc for ResponseRecorder.Result guarantees that the body of the returned
http.Response will be non-nil, but this only holds true if the caller's body is
non-nil. With this change, if the caller's body is nil then the returned
response's body will be an empty io.ReadCloser.
Fixes#26442
Change-Id: I3b2fe4a2541caf9997dbb8978bbaf1f58cd1f471
GitHub-Last-Rev: d802967d89
GitHub-Pull-Request: golang/go#26453
Reviewed-on: https://go-review.googlesource.com/124875
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Rejigger the DWARF tests to ensure that they run in a reasonable
amount of time in short mode, particularly the "abstract origin
sanity" testpoints.
Updates #26470
Change-Id: Idae9763ac20ea999fa394595aacfcd1e271293ae
Reviewed-on: https://go-review.googlesource.com/125295
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Change-Id: I3bcf8850ad3873f2627ba017cbfb8b7a8c9cf467
Reviewed-on: https://go-review.googlesource.com/125256
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If we have go get -u x1@v1 x2@v2 and x1 depends on x2,
use v2 as the "upgraded" x2 chosen by -u instead of
letting -u pick something (say, v2.1) and then immediately
overriding it. This avoids chasing down the deps from v2.1
and also avoids them polluting the overall module graph.
This fix also lets us delete some code in the preparation step,
reducing the overall latency of get -u.
Suggested by Bryan Mills in
https://go-review.googlesource.com/c/vgo/+/122396/6#371.
Fixes#26342.
Change-Id: I50fa842304820d3f16f66a8e65dea695e2b0f88b
Reviewed-on: https://go-review.googlesource.com/124856
Reviewed-by: Bryan C. Mills <bcmills@google.com>
If x v1.0.0 requires y v1.2.0, then
go get x@v1.0.0 y@v1.0.0 needs to fail gracefully.
Fixes#25917.
Change-Id: I9b426af23a30310fcb0c3545a8d97feb58b8ddbe
Reviewed-on: https://go-review.googlesource.com/124800
Reviewed-by: Bryan C. Mills <bcmills@google.com>
While writing the GOPROXY docs it occurred to me that versions
can contain upper-case letters as well. The docs therefore say
that versions are case-encoded the same as paths in the proxy
protocol (and therefore in the cache as well). Make it so.
Change-Id: Ibc0c4af0192a4af251e5dd6f2d36cda7e529099a
Reviewed-on: https://go-review.googlesource.com/124795
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Use the dedicated AES* and PMULL* instructions to accelerate AES-GCM
name old time/op new time/op delta
AESGCMSeal1K-46 12.1µs ± 0% 0.9µs ± 0% -92.66% (p=0.000 n=9+10)
AESGCMOpen1K-46 12.1µs ± 0% 0.9µs ± 0% -92.43% (p=0.000 n=10+10)
AESGCMSign8K-46 58.6µs ± 0% 2.1µs ± 0% -96.41% (p=0.000 n=9+8)
AESGCMSeal8K-46 92.8µs ± 0% 5.7µs ± 0% -93.86% (p=0.000 n=9+9)
AESGCMOpen8K-46 92.9µs ± 0% 5.7µs ± 0% -93.84% (p=0.000 n=8+9)
name old speed new speed delta
AESGCMSeal1K-46 84.7MB/s ± 0% 1153.4MB/s ± 0% +1262.21% (p=0.000 n=9+10)
AESGCMOpen1K-46 84.4MB/s ± 0% 1115.2MB/s ± 0% +1220.53% (p=0.000 n=10+10)
AESGCMSign8K-46 140MB/s ± 0% 3894MB/s ± 0% +2687.50% (p=0.000 n=9+10)
AESGCMSeal8K-46 88.2MB/s ± 0% 1437.5MB/s ± 0% +1529.30% (p=0.000 n=9+9)
AESGCMOpen8K-46 88.2MB/s ± 0% 1430.5MB/s ± 0% +1522.01% (p=0.000 n=8+9)
This change mirrors the current amd64 implementation, and provides optimal performance
on a range of arm64 processors including Centriq 2400 and Apple A12. By and large it is
implicitly tested by the robustness of the already existing amd64 implementation.
The implementation interleaves GHASH with CTR mode to achieve the highest possible
throughput, it also aggregates GHASH with a factor of 8, to decrease the cost of the
reduction step.
Even thought there is a significant amount of assembly, the code reuses the go
code for the amd64 implementation, so there is little additional go code.
Since AES-GCM is critical for performance of all web servers, this change is
required to level the playfield for arm64 CPUs, where amd64 currently enjoys an
unfair advantage.
Ideally both amd64 and arm64 codepaths could be replaced by hypothetical AES and
CLMUL intrinsics, with a few additional vector instructions.
Fixes#18498Fixes#19840
Change-Id: Icc57b868cd1f67ac695c1ac163a8e215f74c7910
Reviewed-on: https://go-review.googlesource.com/107298
Run-TryBot: Vlad Krasnov <vlad@cloudflare.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I forgot to run trybots on CL 123758, and the test failed on Windows because I
hard-coded a slash-delimited path.
Use the tent-in-a-box operator ([/\\]) to make the path platform-agnostic.
Change-Id: I9113ab60d21152c11e2ebdf822b58a44b1b38574
Reviewed-on: https://go-review.googlesource.com/125115
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The test runs far too long for -short mode (4 seconds).
Also removed useless test of now-disconnected knob
(GO_SSA_PHI_LOC_CUTOFF), which cuts 4 seconds to 2 seconds (which
is still too long), and finished removing the disconnected knob.
Updates #26469.
Change-Id: I6c594227c4a5aaffee46832049bdbbf570d86e60
Reviewed-on: https://go-review.googlesource.com/125075
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
If the the package cannot be built,
"go test" and "go vet" should not run the "vet" tool.
In that case only errors from the compilers will be displayed.
Fixes#26125
Change-Id: I5da6ba64bae5f44feaf5bd4e765eea85533cddd4
Reviewed-on: https://go-review.googlesource.com/123938
Run-TryBot: Yury Smolsky <yury@smolsky.by>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 123577 added TestScript. The install_rebuild_gopath
test was failing on Plan 9 because it defines a GOPATH
using the ':' separator, while Plan 9 expects the '\000'
separator in environment variables.
This change fixes the script engine by defining a new
":" environment variable set to OS-specific path list
separator.
The install_rebuild_gopath test has been updated to use
"${:}" instead of ":".
Fixes#26421.
Change-Id: I58a97f882cdb48cc0836398b0d98a80ea58041ba
Reviewed-on: https://go-review.googlesource.com/124435
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When using callbacks, it is not necessarily a deadlock if there is no
runnable goroutine, since a callback might still be pending. If there
is no callback pending, Node.js simply exits with exit code zero,
which is not desired if the Go program is still considered running.
This is why an explicit check on exit is used to trigger the "deadlock"
error. This CL makes it so this is Go's normal "deadlock" error, which
includes the stack traces of all goroutines.
Updates #26382
Change-Id: If88486684d0517a64f570009a5ea0ad082679a54
Reviewed-on: https://go-review.googlesource.com/123936
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It's important for a smooth transition for non-module users
not to change operation in GOPATH/src by default in Go 1.11,
even if go.mod exists in a downloaded dependency.
Even so, users create go.mod and then are confused about
why 'go get' commands seem to behave oddly, when in fact
they are getting the old 'go get'.
Try to split the difference by printing a warning in 'go get'
when run in a tree that would normally be considered a
module if only it were outside GOPATH/src.
Change-Id: I55a1cbef127f3f36de54a8d7b93e1fc64bf0a708
Reviewed-on: https://go-review.googlesource.com/124859
Reviewed-by: Bryan C. Mills <bcmills@google.com>
If there was a mod and non-mod meta tag for a given prefix,
the meta tag extractor was already dropping the non-mod meta tag.
But we might have mod and non-mod meta tags with different
prefixes, in which case the mod tag should prevail when both match.
Fixes#26200.
Change-Id: I17ab361338e270b9fa03999ad1954f2bbe0f5017
Reviewed-on: https://go-review.googlesource.com/124714
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Updates http2 to x/net/http2 git rev a680a1efc54 for:
http2: reject large SETTINGS frames or those with duplicates
https://golang.org/cl/124735
Change-Id: I2168d1d1eef9c63b1a9c06b514b77fae16f920ed
Reviewed-on: https://go-review.googlesource.com/125036
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This was an unfortunate debugging print introduced
while working on the unfortunately large CL 123576.
At least now we're done with that awfulness.
Change-Id: Ib83db59382a799f649832d22d3c6f039d2ef9d2c
Reviewed-on: https://go-review.googlesource.com/125015
Reviewed-by: Bryan C. Mills <bcmills@google.com>
go.sum accumulates cruft as modules are added and removed as
direct and indirect dependencies. Instead of exposing all that cruft,
let "go mod -sync" clean it out.
Fixes#26381.
Change-Id: I7c9534cf7cc4579f7f82646d00ff691c87a13c4a
Reviewed-on: https://go-review.googlesource.com/124713
Reviewed-by: Bryan C. Mills <bcmills@google.com>
People are (understandably) confused by creating go.mod files in GOPATH/src
and then having the go command not use modules in those directories.
We can't change that behavior (or we'll break non-module users of GOPATH)
but we can force 'go mod' (including 'go mod -init') to fail loudly in that case.
If this is not enough, the next step would be to print a warning every time
the go command is run in a GOPATH/src directory with a go.mod but
module mode hasn't triggered. But that will annoy all the non-module users.
Hopefully anyone confused will eventually run a 'go mod' command of
some kind, which will fail loudly.
Fixes#26365.
Change-Id: I8c5fe987fbc3f8d2eceb1138e6862a391ade150c
Reviewed-on: https://go-review.googlesource.com/124708
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Also document module use of GOPATH including GOPATH/src/mod
and GOPATH/bin (unless GOBIN is set).
Fixes#26399.
Fixes#26406.
Change-Id: I7be8eaf110f4fa6fc76ea4cd39aea3dd8addf0b0
Reviewed-on: https://go-review.googlesource.com/124707
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Now pkg@none actually removes the pkg instead of dying.
For #26342.
Change-Id: I9df7281ed8fd24480109b36f33a563f92e279244
Reviewed-on: https://go-review.googlesource.com/124796
Reviewed-by: Bryan C. Mills <bcmills@google.com>
