Michael Fraenkel [Thu, 3 Dec 2020 00:07:27 +0000 (17:07 -0700)]
net/http: add connections back that haven't been canceled
Issue #41600 fixed the issue when a second request canceled a connection
while the first request was still in roundTrip.
This uncovered a second issue where a request was being canceled (in
roundtrip) but the connection was put back into the idle pool for a
subsequent request.
The fix is the similar except its now in readLoop instead of roundTrip.
A persistent connection is only added back if it successfully removed
the cancel function; otherwise we know the roundTrip has started
cancelRequest.
Fixes #42942
Change-Id: Ia56add20880ccd0c1ab812d380d8628e45f6f44c
Reviewed-on: https://go-review.googlesource.com/c/go/+/274973
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Damien Neil <dneil@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Haoran Luo [Tue, 8 Dec 2020 14:29:04 +0000 (14:29 +0000)]
runtime: prevent stack growth after fork in runtime.sigfillset
This fixes the unexpected growth of stack in child process, which
is caused by stack checking code in runtime.sigfillset called from
runtime.sigset while clearing the signal handlers in child process.
The redundant stack checking code is generated due to missing
'//go:nosplit' directive that should be annotated for
runtime.sigfillset.
Fixes #43066
Updates #21314
Change-Id: I9483a962a4b0747074313991841e2440ee32198c
Reviewed-on: https://go-review.googlesource.com/c/go/+/276173
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Austin Clements <austin@google.com>
Keith Randall [Tue, 8 Dec 2020 22:07:19 +0000 (14:07 -0800)]
cmd/vet: vendor in x/tools, enable framepointer vet check
Vendor in latest x/tools.
Add framepointer vet check to vet.
Fixes #43014
Change-Id: Ife72f85b1261aa60c0028041c58040d60a40918a
Reviewed-on: https://go-review.googlesource.com/c/go/+/276372
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Rob Findley [Tue, 8 Dec 2020 14:44:48 +0000 (09:44 -0500)]
go/types: correct error position for inherited const init expressions
This is a port of CL 275517 from the dev.typeparams branch, to fix the
positioning of error messages for invalid const init expressions that
are inherited.
Differences from CL 275517:
+ The inherited flag is added to the constDecl intermediate
representation.
+ The errpos override is made a positioner, the internal interface
used by go/types to capture error position and span. For const decls
errpos is just set to a singular point, but using positioner is
correct and causes span start and end positions to also be
overridden.
+ Test cases are updated to assert on just 'overflows', as the go/types
error message is, for example, "cannot use 255 + iota (untyped int
constant 256) as byte value in constant declaration (overflows)".
This is more verbose than the compiler's "constant 256 overflows
byte", but changing that is out of scope.
Fixes #42991
Change-Id: I0a71d2290f7fff5513f2a6e49b83e6f0f4da30e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/276172
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
Ian Lance Taylor [Thu, 3 Dec 2020 02:25:19 +0000 (18:25 -0800)]
reflect: document multiple keys in struct tags
For #40281
Fixes #42959
Change-Id: Ibc4769fda1592a1373ec720ea30baf319c0a0136
Reviewed-on: https://go-review.googlesource.com/c/go/+/274448
Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Tonis Tiigi [Sun, 6 Dec 2020 20:13:47 +0000 (20:13 +0000)]
runtime/cgo: fix building on musl
sys/unistd.h only exists in glibc and not in musl so use the standard
location. This is a regression from CL 210639
Change-Id: Idd4c75510d9829316b44300c36c34df6d667cc05
GitHub-Last-Rev: 0fa4162f1c7c460bda7585300285f47d1781985d
GitHub-Pull-Request: golang/go#43038
Reviewed-on: https://go-review.googlesource.com/c/go/+/275732
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Andrew G. Morgan <agm@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Ian Lance Taylor [Sat, 5 Dec 2020 16:08:47 +0000 (08:08 -0800)]
test: add new test that gofrontend failed to handle
The gofrontend code would in some circumstances incorrectly generate a
type descriptor for an alias type, causing the type to fail to be
equal to the unaliased type.
Change-Id: I47d33b0bfde3c72a9a186049539732bdd5a6a96e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275632
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Jason A. Donenfeld [Sun, 29 Nov 2020 12:33:37 +0000 (13:33 +0100)]
syscall: correct CertOpenStore to expect a 0 return value on failure
According to [1], this function returns NULL when it errors, rather than
INVALID_HANDLE_VALUE, which other Win32 functions return. This was
pointed out in CL 273446 for the x/sys package, and this patch here
cleans it up for the syscall package and updates the vendored x/sys
package using the usual `go get/go mod vendor` dance. The function is
currently in use by crypto/x509/root_windows.go, which calls
CertOpenStore(CERT_STORE_PROV_MEMORY), which I assume can fail under OOM
or other weird conditions. Quick reversing indicates that [1] is
correct, as there's a `xor eax, eax` in the error paths of the function
just before jumping to the epilogue.
Change-Id: I77c0b0319c13313212f8710785252c494da56ed5
Reviewed-on: https://go-review.googlesource.com/c/go/+/273827
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Pulls in a fix to make versioned import paths more readable in pprof's
graph view.
Updated via the instructions in README.vendor.
Updates #36905
Change-Id: I6a91de0f4ca1be3fc69d8e1a39ccf4f5bd0387ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/275513
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Dmitri Shuralyov [Thu, 3 Dec 2020 17:07:52 +0000 (17:07 +0000)]
doc/go1.16: document no language changes
There are no language changes in Go 1.16, so document that.
For #40700.
Fixes #42976.
Change-Id: I80b0d2ce6cf550c00c0f026ee59ac9fbce6310be
Reviewed-on: https://go-review.googlesource.com/c/go/+/275117
Trust: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Wed, 2 Dec 2020 17:49:20 +0000 (12:49 -0500)]
io/fs: add Sub
Sub provides a convenient way to refer to a subdirectory
automatically in future operations, like Unix's chdir(2).
The CL also includes updates to fstest to check Sub implementations.
As part of updating fstest, I changed the meaning of TestFS's
expected list to introduce a special case: if you list no expected files,
that means the FS must be empty. In general it's OK not to list all
the expected files, but if you list none, that's almost certainly a
mistake - if your FS were broken and empty, you wouldn't find out.
Making no expected files mean "must be empty" makes the mistake
less likely - if your file system ever worked, then your test will keep
it working.
That change found a testing bug: embedtest was making exactly
that mistake.
Fixes #42322.
Change-Id: I63fd4aa866b30061a0e51ca9a1927e576d6ec41e
Reviewed-on: https://go-review.googlesource.com/c/go/+/274856
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Dmitri Shuralyov [Thu, 3 Dec 2020 22:29:39 +0000 (17:29 -0500)]
doc/go1.16: preannounce dropping macOS 10.12 support
Go 1.16 will be the last to support macOS 10.12 Sierra.
Go 1.17 will require macOS 10.13 High Sierra.
For #23011.
Change-Id: I80052bdde4d9f1c5d71b67b85f65fb0b40856750
Reviewed-on: https://go-review.googlesource.com/c/go/+/275299
Trust: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Cherry Zhang [Thu, 3 Dec 2020 18:32:11 +0000 (13:32 -0500)]
cmd/compile: make sure address of offset(SP) is rematerializeable
An address of offset(SP) may point to the callee args area, and
may be used to move things into/out of the args/results. If an
address like that is spilled and picked up by the GC, it may hold
an arg/result live in the callee, which may not actually be live
(e.g. a result not initialized at function entry). Make sure
they are rematerializeable, so they are always short-lived and
never picked up by the GC.
This CL changes 386, PPC64, and Wasm. On AMD64 we already have
the rule (line 2159). On other architectures, we already have
similar rules like
(OffPtr [off] ptr:(SP)) => (MOVDaddr [int32(off)] ptr)
to avoid this problem. (Probably me in the past had run into
this...)
Fixes #42944.
Change-Id: Id2ec73ac08f8df1829a9a7ceb8f749d67fe86d1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275174
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Michael Pratt [Wed, 2 Dec 2020 17:19:13 +0000 (12:19 -0500)]
runtime, time: strictly enforce when, period constraints
timer.when must always be positive. addtimer and modtimer already check
that it is non-negative; we expand it to include zero. Also upgrade from
pinning bad values to throwing, as these values shouldn't be possible to
pass (except as below).
timeSleep may overflow timer.nextwhen. This would previously have been
pinned by resetForSleep, now we fix it manually.
runOneTimer may overflow timer.when when adding timer.period. Detect
this and pin to maxWhen.
addtimer is now too strict to allow TestOverflowRuntimeTimer to test an
overflowed timer. Such a timer should not be possible; to help guard
against accidental inclusion siftup / siftdown will check timers as it
goes. This has been replaced with tests for period and sleep overflows.
Change-Id: I17f9739e27ebcb20d87945c635050316fb8e9226
Reviewed-on: https://go-review.googlesource.com/c/go/+/274853
Trust: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Pratt [Tue, 1 Dec 2020 22:24:33 +0000 (17:24 -0500)]
time, runtime: don't set timer when = 0
timer when == 0, in the context of timer0When and timerModifiedEarliest,
is a sentinel value meaning there are no timers on the heap.
TestCheckRuntimeTimerOverflow reaching into the runtime to set a timer
to when = 0 when it is otherwise not possible breaks this invariant.
After golang.org/cl/258303, we will no longer detect and run this timer,
thus blocking any other timers lower on the heap from running. This
manifests as random timers failing to fire in other tests.
The need to set this overflowed timer to when = 0 is gone with the old
timer proc implementation, so we can simply remove it.
Fixes #42424
Change-Id: Iea32100136ad8ec1bedfa77b1e7d9ed868812838
Reviewed-on: https://go-review.googlesource.com/c/go/+/274632 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Pratt <mpratt@google.com>
Change-Id: Ie3c8a4650cd8f4c239bdceac25dc188a6a50ca34
Reviewed-on: https://go-review.googlesource.com/c/go/+/275178
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
Jonathan Albrecht [Wed, 2 Dec 2020 15:44:10 +0000 (10:44 -0500)]
math/big: remove the s390x assembly for shlVU and shrVU
The s390x assembly for shlVU does a forward copy when the shift amount s
is 0. This causes corruption of the result z when z is aliased to the
input x.
This fix removes the s390x assembly for both shlVU and shrVU so the pure
go implementations will be used.
Test cases have been added to the existing TestShiftOverlap test to
cover shift values of 0, 1 and (_W - 1).
Fixes #42838
Change-Id: I75ca0e98f3acfaa6366a26355dcd9dd82499a48b
Reviewed-on: https://go-review.googlesource.com/c/go/+/274442
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Martin Möhrmann [Thu, 3 Dec 2020 15:41:57 +0000 (16:41 +0100)]
internal/cpu: disable FMA when OSXSAVE is not enabled on x86
All instructions in the FMA extension on x86 are VEX prefixed.
VEX prefixed instructions generally require OSXSAVE to be enabled.
The execution of FMA instructions emitted by the Go compiler on amd64
will generate an invalid opcode exception if OSXSAVE is not enabled.
Fixes #41022
Change-Id: I49881630e7195c804110a2bd81b5bec8cac31ba8
Reviewed-on: https://go-review.googlesource.com/c/go/+/274479
Trust: Martin Möhrmann <moehrmann@google.com>
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Ian Lance Taylor [Thu, 3 Dec 2020 02:13:14 +0000 (18:13 -0800)]
test: match gccgo error messages
assign.go:59:28: error: ‘x’ repeated on left side of :=
assign.go:65:20: error: ‘a’ repeated on left side of :=
method2.go:36:11: error: reference to method ‘val’ in type that is pointer to interface, not interface
method2.go:37:11: error: reference to method ‘val’ in type that is pointer to interface, not interface
Change-Id: I8f385c75a82fae4eacf4618df8f9f65932826494
Reviewed-on: https://go-review.googlesource.com/c/go/+/274447
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Returning an error about integer overflow is needlessly pedantic.
The meaning of ReadForm(MaxInt64) is easily understood
(accept a lot of data) and can be implemented.
Fixes #40430.
Change-Id: I8a522033dd9a2f9ad31dd2ad82cf08d553736ab9
Reviewed-on: https://go-review.googlesource.com/c/go/+/275112
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Cherry Zhang [Tue, 17 Nov 2020 02:28:26 +0000 (21:28 -0500)]
cmd/compile, runtime: use __msan_memmove for moving data, split msanread to fields
Currently, for data moving, we generate an msanread of the source,
followed by an msanwrite of the destination. msanread checks
the source is initialized.
This has a problem: if the source is an aggregate type containing
alignment paddings, the padding bytes may not be thought as
initialized by MSAN. If we copy the aggregate type by value, if
it counts as a read, MSAN reports using uninitialized data. This
CL changes it to use __msan_memmove for data copying, which tells
MSAN to propagate initialized-ness but not check for it.
Caveat: technically __msan_memmove is not a public API of MSAN,
although the C compiler does generate direct calls to it.
Also, when instrumenting a load of a struct, split the
instrumentation to fields, instead of generating an msanread for
the whole struct. This skips padding bytes, which may not be
considered initialized in MSAN.
Russ Cox [Wed, 2 Dec 2020 15:14:53 +0000 (10:14 -0500)]
cmd/go: stop tests from using network during -short
It turned out that "go get" was using the network to look up
https://github.com?go-get=1 while resolving github.com/google/go-cmp,
and that is not the fastest page to load.
Stop that lookup by adjusting the path prefixes in the vcs table.
It also turned out that "go get" was using the network to look up
https://rsc.io?go-get=1 while resolving https://rsc.io/nonexist.svn.
That's a bit more defensible maybe, since rsc.io is not a known VCS host.
But for tests we really want to avoid the network entirely, so this CL
adds a special case in repoRootFromVCSPaths that returns a hard error
for plain "rsc.io" instead of doing the web fetch.
To keep us honest in the future, I added two automatically-set env
variables TESTGONETWORK=panic and TESTGOVCS=panic.
These cause the go command to panic rather than make a network request
or invoke a VCS command.
go test -short cmd/go now passes with these checks.
This reduced the time spent in go test -short cmd/go on my
Google workstation from 154s to 30s. (Yay network firewalls.)
Change-Id: I49207fca7f901fa011765fb984dc9cec8b691f11
Reviewed-on: https://go-review.googlesource.com/c/go/+/274441
Trust: Russ Cox <rsc@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
io/ioutil was a poorly defined collection of helpers.
Proposal #40025 moved out the generic I/O helpers to io.
This CL for proposal #42026 moves the OS-specific helpers to os,
making the entire io/ioutil package deprecated.
Cuong Manh Le [Tue, 1 Dec 2020 15:23:42 +0000 (22:23 +0700)]
doc: update signal.Notify example to use buffered channel
This if follow up of CL 274332.
Updates #9399.
Change-Id: Ic6dd534dc18227a799cbb9577979f2285596b825
Reviewed-on: https://go-review.googlesource.com/c/go/+/274393
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Cuong Manh Le [Tue, 1 Dec 2020 05:54:24 +0000 (12:54 +0700)]
cmd/go: fix unbuffered channel passed to signal.Notify
Unbuffered channels passed into signal.Notify can be lost
as the docs for signal.Notify caution with:
Package signal will not block sending to c: the caller must ensure
that c has sufficient buffer space to keep up with the expected signal
rate. For a channel used for notification of just one signal value,
a buffer of size 1 is sufficient.
Found by a static analyzer from Orijtech, Inc. called "sigchanyzer", but
it'll be donated to the Go project soon.
Updates #9399.
Change-Id: Ia0690e447582da028694ed65ace7b97961997b84
Reviewed-on: https://go-review.googlesource.com/c/go/+/274332
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Pseudo branch instructions BGT, BGTU, BLE, and BLEU implemented In
CL 226397 were translated inconsistently compared to other ones due
to the inversion of registers. For instance, while "BLT a, b" generates
"jump if a < b", "BLE a, b" generates "jump if b <= a."
This CL fixes the translation in the assembler and the tests.
Change-Id: Ia757be73e848734ca5b3a790e081f7c4f98c30f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/271911 Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Ian Lance Taylor [Wed, 2 Dec 2020 02:14:40 +0000 (18:14 -0800)]
test: match gofrontend error messages
The gofrontend code doesn't distinguish semicolon and newline,
and it doesn't have special treatment for EOF.
syntax/semi6.go:9:47: error: unexpected semicolon or newline in type declaration
syntax/semi6.go:11:62: error: unexpected semicolon or newline in type declaration
Change-Id: I9996b59a4fc78ad1935e779f354ddf75c0fb44e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/274692
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Cherry Zhang [Sun, 22 Nov 2020 16:43:29 +0000 (11:43 -0500)]
cmd/link: invalidate kernel cache on darwin
Apparently, the darwin kernel may cache the code signature at
mmap. When we mmap the output buffer, it doesn't have a code
signature (as we haven't generated one). Invalidate the kernel
cache after writing the file.
See https://github.com/golang/go/issues/42684#issuecomment-731704900
for more information.
Cherry Zhang [Sun, 22 Nov 2020 02:24:57 +0000 (21:24 -0500)]
cmd/internal/buildid: update Mach-O code signature when rewriting buildid
As the code signature contains hashes of the entire file (except
the signature itself), rewriting buildid will invalidate the
signature. This CL makes it regenerate the signature when
rewriting the buildid. It only does it when the file already has
a code signature, with proper size (darwin/arm64 binaries
generated by the Go linker should have).
Cherry Zhang [Sun, 22 Nov 2020 01:11:03 +0000 (20:11 -0500)]
cmd/link: code-sign on darwin/arm64
This CL lets the linker code-sign output binaries on
darwin/arm64, as the kernel requires binaries must be signed in
order to run.
This signature will likely be invalidated when we stamp the
buildid after linking. We still do it in the linker, for
- plain "go tool link" works.
- the linker generates the LC_CODE_SIGNATURE load command with
the right size and offset, so we don't need to update it when
stamping the buildid.
Jason A. Donenfeld [Mon, 30 Nov 2020 09:41:46 +0000 (10:41 +0100)]
cmd/compile: do not assume TST and TEQ set V on arm
These replacement rules assume that TST and TEQ set V. But TST and
TEQ do not set V. This is a problem because instructions like LT are
actually checking for N!=V. But with TST and TEQ not setting V, LT
doesn't do anything meaningful. It's possible to construct trivial
miscompilations from this, such as:
package main
var x = [4]int32{-0x7fffffff, 0x7fffffff, 2, 4}
func main() {
if x[0] > x[1] {
panic("fail 1")
}
if x[2]&x[3] < 0 {
panic("fail 2") // Fails here
}
}
That first comparison sets V, via the CMP that subtracts the values
causing the overflow. Then the second comparison operation thinks that
it uses the result of TST, when it actually uses the V from CMP.
Before this fix:
TST R0, R1
BLT loc_6C164
After this fix:
TST R0, R1
BMI loc_6C164
The BMI instruction checks the N flag, which TST sets. This commit
fixes the issue by using [LG][TE]noov instead of vanilla [LG][TE], and
also adds a test case for the direct issue.
Fixes #42876.
Change-Id: I13c62c88d18574247ad002b671b38d2d0b0fc6fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/274026
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reason for revert: Broke many tests inside Google which implies many
tests were broken outside of Google as well. The tests may be brittle
but still would require work to change and it's not clear it's worth
the benefit.
Updates #36221
Fixes #42675
Change-Id: Id3a14eb37e7119f5abe50e80dfbf120fdc44db72
Reviewed-on: https://go-review.googlesource.com/c/go/+/273747
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Trust: Joe Tsai <thebrokentoaster@gmail.com>
Cherry Zhang [Sat, 21 Nov 2020 22:43:16 +0000 (17:43 -0500)]
cmd/internal/buildid: exclude Mach-O code signature in hash calculation
The code signature contains hashes of the entire file (except the
signature itself), including the buildid. Therefore, the buildid
cannot depend on the signature. Otherwise updating buildid will
invalidate the signature, and vice versa. As we cannot change the
code-signing algorithm, we can only change buildid calculation.
This CL changes the buildid calculation to exclude the Mach-O
code signature. So updating code signature after stamping the
buildid will not invalidate the buildid.
Cherry Zhang [Sun, 22 Nov 2020 02:33:18 +0000 (21:33 -0500)]
cmd/internal/codesign: new package
On macOS/ARM64, the kernel requires that binaries must have a
valid code signature to run. The C toolchain code-signs the
binary at link time. We do the same.
It is more subtle for Go because we stamp the buildid after
linking. As the signature contains hashes of the entire file
(except the signature itself), we must (re)generate the signature
after stamping the buildid.
This CL adds a new codesign package, which provides
functionality to generate the code signature. It is a separate
internal package so it can be used both in the linker and by the
go command. The next CLs will add code-signing to the linker and
the go command.
Jay Conrod [Tue, 1 Dec 2020 18:51:17 +0000 (13:51 -0500)]
cmd/go: don't print deprecation notice for 'go get exe'
It's difficult for module authors to provide installation instructions
that work in both Go 1.15 and 1.16. We'll wait until 1.17 to print a
deprecation warning for installing executables with 'go get'.
Fixes #42885
Change-Id: I835b447e83e760f48fd664e8a117749e0cb59f83
Reviewed-on: https://go-review.googlesource.com/c/go/+/274552
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Anmol Sethi [Sat, 24 Oct 2020 00:40:41 +0000 (00:40 +0000)]
net/http: allow upgrading non keepalive connections
If one was using http.Transport with DisableKeepAlives and trying
to upgrade a connection against net/http's Server, the Server
would not allow a "Connection: Upgrade" header to be written
and instead override it to "Connection: Close" which would
break the handshake.
This change ensures net/http's Server does not override the
connection header for successful protocol switch responses.
Joel Sing [Thu, 26 Nov 2020 15:06:08 +0000 (02:06 +1100)]
cmd/link/internal/amd64: always generate R_X86_64_PLT32 for SDYNIMPORT calls
Currently, in the non-DynlinkingGo case with external linking, we generate a
R_X86_64_GOTPCREL relocation for the imported symbol. This results in the
external linker turning this into a R_X86_64_GLOB_DAT relocation, rather
than a R_X86_64_JUMP_SLOT. Always generate R_X86_64_PLT32 for SDYNIMPORT
calls so that these calls work correctly.
Update #36435
Fixes #42671
Change-Id: I8a28884b7853cb4135053ed817bedc919482f4ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/270377
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Cherry Zhang [Fri, 27 Nov 2020 05:42:41 +0000 (00:42 -0500)]
runtime: mlock signal stack on macOS/ARM64
Apparently, the macOS ARM64 kernel has a bug where when a signal
arrives and the signal stack is not currently faulted in, it may
kill the program with a SIGILL. Work around it by mlock the
signal stacks.
Jay Conrod [Mon, 30 Nov 2020 20:46:33 +0000 (15:46 -0500)]
cmd/go: fix infinite loop in modload.keepSums
Fixes #42891
Change-Id: I0cce4204a1c4959b896188a2ab3719c0507f95e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/274172
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Andy Pan [Sat, 21 Nov 2020 06:48:26 +0000 (14:48 +0800)]
net: add note about disabling loopback in ListenMulticastUDP()
Fixes #41752
Change-Id: I83520d2303e5fd2e5f6329f092b40e73c13771a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/271908 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Ian Lance Taylor [Sun, 29 Nov 2020 03:10:57 +0000 (19:10 -0800)]
test: update gofrontend expected errors
This matches the error messages after CL 273890.
syntax/semi4.go:11:9: error: unexpected semicolon or newline, expecting ‘{’ after for clause
syntax/semi4.go:10:13: error: reference to undefined name ‘x’
syntax/semi4.go:12:17: error: reference to undefined name ‘z’
Change-Id: Ic88ff6e27d50bf70f5b2114383b84c42c0682f39
Reviewed-on: https://go-review.googlesource.com/c/go/+/273891
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Ian Lance Taylor [Sun, 29 Nov 2020 02:14:38 +0000 (18:14 -0800)]
test: recognize gofrontend error messages
shift1.go:76:16: error: shift of non-integer operand
shift1.go:77:16: error: shift of non-integer operand
Change-Id: I48584c0b01f9f6912a93b5f9bba55b5803fbeced
Reviewed-on: https://go-review.googlesource.com/c/go/+/273888
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Ian Lance Taylor [Sun, 29 Nov 2020 01:51:18 +0000 (17:51 -0800)]
test: recognize new gofrontend error message
As of https://golang.org/cl/273886:
fixedbugs/bug340.go:15:18: error: reference to method ‘x’ in interface with no methods
For golang/go#10700
Change-Id: Id29eb0e34bbb524117614229c4c27cfd17dae286
Reviewed-on: https://go-review.googlesource.com/c/go/+/273887
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Joshua M. Clulow [Mon, 30 Nov 2020 01:18:51 +0000 (17:18 -0800)]
os/exec: constrain thread usage in leaked descriptor test on illumos
On illumos systems, libc can under some conditions make use of files
from /proc. In the case of this test, the creation of new threads was
(in the target thread) causing libc to open and close
"/proc/self/lwp/5/lwpname" to set the thread name, which raced with the
leaking descriptor check (see detailed analysis in #42431).
This change requests that the Go runtime use less threads in the child
process used to check for leaked descriptors, without just disabling the
test. After a thousand repeated trials, the test no longer fails on
illumos.
Fixes #42431.
Change-Id: Iefda26134fc91f7cb205754676e9845d9b7205cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/273966 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Jason A. Donenfeld [Sat, 28 Nov 2020 13:38:29 +0000 (14:38 +0100)]
runtime/pprof: ignore test failures on windows/arm
This is blocking forward progress of the de-bitrotting work, and I don't
know off hand how to fix this. Seeing as its disabled on other
platforms, I suspect pprof might not be a very reliable feature, so just
allow for the tests to fail for now, until somebody more motivated comes
along to fix it.
Updates #42862.
Change-Id: Ibc5cd1d82d97b9c2f887d7f3565f2fa70207c8b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/273826
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Ian Lance Taylor [Thu, 26 Nov 2020 20:26:02 +0000 (12:26 -0800)]
test: match gofrontend error messages
These changes match the following gofrontend error messages:
blank1.go:16:1: error: may not define methods on non-local type
chan/perm.go:28:9: error: expected channel
chan/perm.go:29:11: error: left operand of ‘<-’ must be channel
chan/perm.go:69:9: error: argument must be channel
complit1.go:25:16: error: attempt to slice object that is not array, slice, or string
complit1.go:26:16: error: attempt to slice object that is not array, slice, or string
complit1.go:27:17: error: attempt to slice object that is not array, slice, or string
complit1.go:49:41: error: may only omit types within composite literals of slice, array, or map type
complit1.go:50:14: error: expected struct, slice, array, or map type for composite literal
convlit.go:24:9: error: invalid type conversion (cannot use type unsafe.Pointer as type string)
convlit.go:25:9: error: invalid type conversion (cannot use type unsafe.Pointer as type float64)
convlit.go:26:9: error: invalid type conversion (cannot use type unsafe.Pointer as type int)
ddd1.go:63:9: error: invalid use of ‘...’ calling non-variadic function
fixedbugs/bug176.go:12:18: error: index expression is not integer constant
fixedbugs/bug332.go:17:10: error: use of undefined type ‘T’
fixedbugs/issue4458.go:19:14: error: type has no method ‘foo’
fixedbugs/issue5172.go:24:14: error: too many expressions for struct
init.go:17:9: error: reference to undefined name ‘runtime’
initializerr.go:26:29: error: duplicate value for index 1
interface/explicit.go:60:14: error: type assertion only valid for interface types
label.go:64:9: error: reference to undefined label ‘go2’
label1.go:18:97: error: continue statement not within for
label1.go:22:97: error: continue statement not within for
label1.go:106:89: error: continue statement not within for
label1.go:108:26: error: invalid continue label ‘on’
label1.go:111:118: error: break statement not within for or switch or select
label1.go:113:23: error: invalid break label ‘dance’
map1.go:64:9: error: not enough arguments
map1.go:65:9: error: not enough arguments
map1.go:67:9: error: argument 1 must be a map
method2.go:36:11: error: reference to undefined field or method ‘val’
method2.go:37:11: error: reference to undefined field or method ‘val’
method2.go:41:12: error: method requires pointer (use ‘(*T).g’)
syntax/chan1.go:13:19: error: send statement used as value; use select for non-blocking send
syntax/chan1.go:17:11: error: send statement used as value; use select for non-blocking send
Change-Id: I98047b60a376e3d2788836300f7fcac3f2c285cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/273527
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Jason A. Donenfeld [Thu, 26 Nov 2020 21:38:45 +0000 (22:38 +0100)]
cmd/link: mark windows/arm as all PIE
If the linker thinks that it's in exe mode instead of pie mode, it
won't emit relocations when generating the pcln table, and we wind
up with crashes like this on windows/arm, where all binaries are
in fact relocated:
Building Go toolchain2 using go_bootstrap and Go toolchain1.
fatal error: minpc or maxpc invalid
runtime: panic before malloc heap initialized
This problem was already solved by darwin/arm64, so solve it the same
way here for windows/arm.
Fixes CL 228478.
Fixes #42786.
Change-Id: I6d1db6907c131183649fc263ccca06783188f344
Reviewed-on: https://go-review.googlesource.com/c/go/+/273566
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Jason A. Donenfeld [Fri, 27 Nov 2020 21:07:23 +0000 (22:07 +0100)]
runtime: adjust address calculation in identifying abort on windows/arm
Apparently we're being called on arm 1 byte off, just like on 386 and
amd64, so unify the handler for isAbortPC.
Fixes #42859.
Updates #29050.
Change-Id: I97fffeb4a33d93ca3397ce1c9ba2b05137f391ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/273727
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Jason A. Donenfeld [Fri, 27 Nov 2020 19:45:15 +0000 (20:45 +0100)]
runtime: return 0 from C function in test
This function's prototype includes a return value, so return a value.
Otherwise clang gets upset:
--- FAIL: TestDLLPreloadMitigation (1.40s)
syscall_windows_test.go:986: failed to build dll: exit status 1 - nojack.c:7:1: error: non-void function does not return a value [-Werror,-Wreturn-type]
}
^
1 error generated.
Fixes #42860.
Change-Id: I65b8eb9ccb502692c5b65bd34829f331cd86eef0
Reviewed-on: https://go-review.googlesource.com/c/go/+/273726
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Rodolfo Carvalho [Thu, 26 Nov 2020 16:01:35 +0000 (17:01 +0100)]
log: make Default doc comment consistent with package doc
None of the other, older, doc comments use the '*Logger' form, and while
'Logger' and 'logger' are both used in the package doc comment, the
common term used with the intended meaning is 'standard logger', which
appears another eleven times in doc comments.
Change-Id: I089103198fc82390517615eb27bbe7ef77107d34
Reviewed-on: https://go-review.googlesource.com/c/go/+/273486 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Wed, 25 Nov 2020 21:47:42 +0000 (13:47 -0800)]
reflect: fix Value.Convert for int-to-string conversions (regression)
The bug was introduced by https://golang.org/cl/220844.
Updates #42792.
Fixes #42835.
Change-Id: I03065c7526488aded35ef2f800b7162e1606877a
Reviewed-on: https://go-review.googlesource.com/c/go/+/273326
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Dmitri Shuralyov [Wed, 25 Nov 2020 19:07:30 +0000 (14:07 -0500)]
doc/go1.16: consolidate stdlib changes in "Minor changes" section
Many of the standard library changes that were added before CL 272871
ended up in the "Core library" section. That section is meant for
major changes like new packages, and most of these aren't.
Consolidate all changes in the "Minor changes to the library" section
for now, so that it's easier to get a complete picture of changes for
each package, along with the remaining TODOs. Add a TODO to read them
over at the end and factor out items that are worth highlighting.
Apply minor other fixups to improve consistency.
For #40700.
Change-Id: I7dc2e7ebf2ea3385fce0c207bae4ce467998a717
Reviewed-on: https://go-review.googlesource.com/c/go/+/273267
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Elias Naur [Tue, 24 Nov 2020 16:48:38 +0000 (17:48 +0100)]
cmd/internal/objabi: assume GOARM=7 on Android
CL 34641 changed the Go runtime to assume GOARM=7 support on Android.
This change completes that by assuming GOARM=7 in the toolchain, fixing
the gotcha of inexplicably slow performance on non-arm64 Android devices.
There is already code in cmd/dist to force GOARM to 7 on GOOS=android. However,
dist is most likely run with GOOS != android.
Change-Id: I5e2bf11c3ecd0f6c193229eaa8ddc570722799d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/272846
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Elias Naur <mail@eliasnaur.com>