In Go 1.12, we added a heuristic to 'go mod tidy' to resolve packages
by adding replaced-but-not-required modules before falling back to
searching for modules from the network. Unfortunately, that heuristic
fails when the replaced version is already lower than the selected
version: adding such a module to the build list doesn't change the
selected version of that module, and so it doesn't make progress
toward resolving the missing package.
Fixes#46659
Change-Id: I75e2387d5290e769f6b0fa1231dcc4605db68597
Reviewed-on: https://go-review.googlesource.com/c/go/+/330432
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The helper function claims that dialing a closed port should be
"nearly instantaneous", but that is empirically not the case on
OpenBSD or Windows. The tests do not appear to be particularly
sensitive to the exact upper bound otherwise, so let's just
remove the arbitrary latency assumption.
Fixes#46884
Change-Id: If00c9fdc3063da6aaf60d365d4a2ee2c94dc6df1
Reviewed-on: https://go-review.googlesource.com/c/go/+/330250
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#46883
Updates CL 267017
Change-Id: I15c307bfb0aaa2877a148d32527681f79df1a650
Reviewed-on: https://go-review.googlesource.com/c/go/+/330289
Reviewed-by: Kevin Burke <kev@inburke.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
When we are looking for a dependency cycle involving a specific
package, we need to keep track of visited packages in order to avoid
repeatedly traversing a cycle that does not involve that package.
If we're keeping track of all visited packages anyway, we're already
spending O(N) memory on the traversal, so we may as well use
breadth-first search. That not only keeps the bookkeeping simple, but
also guarantees that we will find a shortest path (rather than a
completely arbitrary one).
Fixes#45863
Change-Id: I810c7337857e42dcb83630abbdea75021554be45
Reviewed-on: https://go-review.googlesource.com/c/go/+/330430
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The real net code uses subtle heuristics to transform a domain name
to its absolute form. Since lookupPTR isn't checking that
transformation specifically, it should use the real code instead of
using a different heuristic.
Fixes#46882
Change-Id: I503357e0f62059c37c359cd54b44d343c7d5ab2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/330249
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The test successfully runs on currently supported versions (6.8 and
6.9) of openbsd.
Fixes#25877
Change-Id: I2694f08c5596b486453c2ac829f17b8bc455f828
Reviewed-on: https://go-review.googlesource.com/c/go/+/329732
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
The build.Context ToolTags value is set based on the set of enabled
experiments, which in turn depends on GOARCH. Before this CL the set
of experiments was being set based on GOARCH in the environment.
That is normally fine, but fails with cmd/go when somebody has run
"go env -w GOARCH=val"; in that case cmd/go changes its GOARCH value
after initialization. The new GOARCH value was affect the set of
enabled experiments, which can affect the ToolTags value. With this
CL, we update ToolTags in cmd/go based on the GOARCH value it is using.
This is a pretty ugly fix. We should do something cleaner for 1.18.
Fixes#46815
Change-Id: Ie9416781a168248813c3da8afdc257acdd3fef7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/329930
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When type checking t[_], where t is a type name, it was possible to leak
an error message related to generics. Fix this by guarding on
typeparams.Enabled.
In order to test this fix, we need to be able to run the new go/types
test only if type parameters are disabled. Introduce the .go1 test data
suffix (similar to .go2) to control this behavior.
Originally found via fuzzing, though the test case was manually
simplified.
Updates #46404
Change-Id: Ib1e2c27cf974c2a5ca5b9d6d01b84a30ba4d583b
Reviewed-on: https://go-review.googlesource.com/c/go/+/329793
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This documentation remained from the original dev.typeparams merge. This
flag no longer exists.
Change-Id: Ic9a82071c512614dc1382780d69ef13253fca21d
Reviewed-on: https://go-review.googlesource.com/c/go/+/329792
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
To be consistent with Go 1.16, and to preserve as much information in
the AST as possible, parse an ast.IndexExpr with BadExpr Index for the
invalid expression a[].
A go/types test had to be adjusted to account for an additional error
resulting from this change.
We don't have a lot of test coverage for parser error recovery, so
rather than write an ad-hoc test for this issue, add a new go/types test
that checks that the indexed operand is used.
Updates #46403
Change-Id: I21e6ff4179746aaa50e530d4091fded450e69824
Reviewed-on: https://go-review.googlesource.com/c/go/+/329791
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
For #46366
Change-Id: I8417e6e4dbb8cb56ff7afc16893a01b7bb938217
Reviewed-on: https://go-review.googlesource.com/c/go/+/329529
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
CL 328770 should be sufficient to fix the specific failure in the
report, but when attempting to reproduce it I noticed a related
failure mode, triggered by the environment variables set in
src/run.bash.
The failure mode is currently masked on the Go project builders due to
the lack of any 'longtest' builder running as a non-root user
(#10719).
It is also masked from Go contributors running 'run.bash' locally
because 'run.bash' does not actually run all of the tests unless
GO_TEST_SHORT=0 is set in the environment (#29266, #46054).
Fixes#46695
Change-Id: I272c09dae462734590dce59b3d3c5b6d3f733c92
Reviewed-on: https://go-review.googlesource.com/c/go/+/328771
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TestAllDependencies is attempting to check that the modules in GOROOT
satisfy certain properties; it should not modify those modules itself.
The “quick” part of the test checks that vendored packages are present
and complete, without constructing a parallel GOROOT. It shouldn't
resolve new dependencies or change formatting in any way.
The longer version of the test already constructs a parallel GOROOT
and tidies the modules within it. That part of the test will flag any
modifications needed to the go.mod and go.sum files, without modifying
the original GOROOT.
From what I can tell, the failure mode in #46695 is caused by running
the test on a module rooted in $GOROOT proper. There is no such module
in the mainline Go repo, but it may have been introduced in the fork
and could also be introduced by stray edits in contributor CLs. It
should be diagnosed clearly.
For #46695
Change-Id: I62b90ccbd54cb3e3b413017021c952a7b1d455e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/328770
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Change-Id: I2d2c02eec4ac6eca218fa5334d32650c1620692c
Reviewed-on: https://go-review.googlesource.com/c/go/+/329689
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
CL 308611 optimized parseIdentifier for ASCII, but inadvertently skipped
error handling for 0 bytes. Don't take the optimized path when
encountering 0.
Fixes#46855
Change-Id: Ic584e077eb74c012611fefa20eb71ca09c81b3c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/329790
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The issue go#46783 correctly diagnosed the context timeout
caused an intermittent failure when the context was canceled
prior to the BeginTx call. However due to the asynchronous nature
of canceling a Tx through a context on fast systems, the tx.Prepare
also succeeded. On slower systems or if a time.Sleep was inserted
between the BeginTx and Prepare, the Prepare would fail.
Resolve this by moving the context cancel after the Prepare.
This will still trigger the deadlock which I tested locally.
In addition, I interspersed multiple time.Sleep calls and the
test still functioned.
Fixes#46852
Change-Id: I9cbf90d3c12b2555493a37799738772b615ae39d
Reviewed-on: https://go-review.googlesource.com/c/go/+/329830
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
This patch reinstates a fix for PowerPC with regard to making VDSO calls
while receiving a signal, and subsequently crashing. The crash happens
because certain VDSO calls can modify the r30 register, which is where g
is stored. This change was reverted for PowerPC because r30 is supposed
to be a non-volatile register. This is true, but that only makes a
guarantee across function calls, but not "within" a function call. This
patch was seemingly fine before because the Linux kernel still had hand
rolled assembly VDSO function calls, however with a recent change to C
function calls it seems the compiler used can generate instructions
which temporarily clobber r30. This means that when we receive a signal
during one of these calls the value of r30 will not be the g as the
runtime expects, causing a segfault.
You can see from this assembly dump how the register is clobbered during
the call:
(the following is from a 5.13rc2 kernel)
```
Dump of assembler code for function __cvdso_clock_gettime_data:
0x00007ffff7ff0700 <+0>: cmplwi r4,15
0x00007ffff7ff0704 <+4>: bgt 0x7ffff7ff07f0 <__cvdso_clock_gettime_data+240>
0x00007ffff7ff0708 <+8>: li r9,1
0x00007ffff7ff070c <+12>: slw r9,r9,r4
0x00007ffff7ff0710 <+16>: andi. r10,r9,2179
0x00007ffff7ff0714 <+20>: beq 0x7ffff7ff0810 <__cvdso_clock_gettime_data+272>
0x00007ffff7ff0718 <+24>: rldicr r10,r4,4,59
0x00007ffff7ff071c <+28>: lis r9,32767
0x00007ffff7ff0720 <+32>: std r30,-16(r1)
0x00007ffff7ff0724 <+36>: std r31,-8(r1)
0x00007ffff7ff0728 <+40>: add r6,r3,r10
0x00007ffff7ff072c <+44>: ori r4,r9,65535
0x00007ffff7ff0730 <+48>: lwz r8,0(r3)
0x00007ffff7ff0734 <+52>: andi. r9,r8,1
0x00007ffff7ff0738 <+56>: bne 0x7ffff7ff07d0 <__cvdso_clock_gettime_data+208>
0x00007ffff7ff073c <+60>: lwsync
0x00007ffff7ff0740 <+64>: mftb r30 <---- RIGHT HERE
=> 0x00007ffff7ff0744 <+68>: ld r12,40(r6)
```
What I believe is happening is that the kernel changed the PowerPC VDSO
calls to use standard C calls instead of using hand rolled assembly. The
hand rolled assembly calls never touched r30, so this change was safe to
roll back. That does not seem to be the case anymore as on the 5.13rc2
kernel the compiler *is* generating assembly which modifies r30, making
this change again unsafe and causing a crash when the program receives a
signal during these calls (which will happen often due to async
preempt). This change happened here:
https://lwn.net/ml/linux-kernel/235e5571959cfa89ced081d7e838ed5ff38447d2.1601365870.git.christophe.leroy@csgroup.eu/.
I realize this was reverted due to unexplained hangs in PowerPC
builders, but I think we should reinstate this change and investigate
those issues separately:
f4ca3c1e0aFixes#46803
Change-Id: Ib18d7bbfc80a1a9cb558f0098878d41081324b52
GitHub-Last-Rev: c3002bcfca
GitHub-Pull-Request: golang/go#46767
Reviewed-on: https://go-review.googlesource.com/c/go/+/328110
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Apparently, TestMorestack is still flaky on darwin/arm64 builder
after CL 307730. Let it spend more time in copying the stack.
With this CL, on my Apple M1 machine it passes reliably in short
mode for 1000 runs, and reliably gets 250+ samples in the 5-second
interval in long mode.
May fix#46755.
Change-Id: I07b36c1cf63ad35f7820e1f8e837e29376a37b2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/329869
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
We've observed some occasional os-arch specific timeouts
in signal.TestSignalTrace(). While the main purpose of a
short timeout is to ensure the passing tests complete
quickly, the unexpected failure path can tolerate waiting
longer (the test is not intended to test how slow or
overloaded the OS is at the time it is run).
Fixes#46736
Change-Id: Ib392fc6ce485a919612784ca88ed76c30f4898e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/329502
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
The new RGBA64At method is equivalent to the existing At method (and the
new SetRGBA64 method is equivalent to the existing Set method in the
image/draw package), but they can avoid allocations from converting
concrete color types to the color.Color interface type.
Also update api/go1.17.txt and doc/go1.17.html
Fixes#44808
Change-Id: I8671f3144512b1200fa373840ed6729a5d61bc35
Reviewed-on: https://go-review.googlesource.com/c/go/+/311129
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
I wrote code that relied on this API, but I misunderstood the original
description of the "more" result. As a consequence, my code always
stopped one frame early.
This CL expands the documentation to be more explicit and specifically
call out my confusion (i.e., that the "more" result indicates whether
the *next* Next call will return a valid Frame, and not whether this
call did).
Change-Id: If135f8f8c05425073d45377c4179e4f79e6bd6ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/329389
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Otherwise, in c-archive or c-shared mode, there is the chance of
getting a SIGPROF just after the signal handler is removed but before
profiling is disabled, in which case the program will die.
Fixes#46498
Change-Id: I5492beef45fec9fb9a7f58724356d6aedaf799ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/329290
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
runtime/pprof has a more complete list of platforms with broken
profiling than I used in cmd/pprof in https://golang.org/cl/325809.
Duplicate that list in cmd/pprof and clean it up a bit in runtime/pprof
for easier reference.
Change-Id: I8f2580aac223de9b73cfff4355f49916f7b76493
Reviewed-on: https://go-review.googlesource.com/c/go/+/329149
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
I left a TODO to decide whether to add 'go get' arguments as indirect
(as we have in the past), or to make them direct. I considered both
options, and decided to keep the indirect default because it is easier
(and less invasive) for users to fix.
Updates #45979
Change-Id: I1f23a88db59a01bdd9e6fe48c2fffc8a3b55145a
Reviewed-on: https://go-review.googlesource.com/c/go/+/328971
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
https://golang.org/cl/318049 replaced driver.ObjFile.Base with
driver.ObjFile.ObjAddr. We don't support shared libraries, so these
should be no-op, but CL 318049 accidentally failed to account from the
change in no-op behavior from returning 0 to passing through addr.
Fixes#46636
Change-Id: Iab82224c7db722a1e257ec6e305218e22114d0a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/325809
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Only use safe characters of the test name for the os.MkdirTemp pattern.
This currently includes the alphanumeric characters and ASCII
punctuation characters known not to interact with globs.
Fixes#46624
Change-Id: I402c34775b943fed9b97963c52f79245cc16dc1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/326010
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Only methods that modify the time take pointer receivers;
IsDST does not modify it and therefore should not.
For #42102 and #46688.
Change-Id: I4721ef7f4d7572236ae6e4d99a459b9ffb11999e
Reviewed-on: https://go-review.googlesource.com/c/go/+/326789
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I needed to also update TestScript/mod_sumdb_golang.
It had been relying on 'go list -mod=mod' to add both the go.mod and
go.sum entries for the named package, but when 'go get' actually adds
all of the needed dependencies, lazy loading kicks in and 'go list'
doesn't end up needing the checksums for go.mod files.
We didn't detect the skew before because the 'go list' command was
(unexpectedly) also adding the missing dependencies, which triggered a
deep scan of the complete module graph.
For #45979
Change-Id: Ica917dee22c83ffa71c6ad0f2e189f911b73edf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/328231
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
If someone sees "in [0,n)" it might look like a typo.
Saying "in the half-open interval [0,n)" will give people
something to search the web for (half-open interval).
Change-Id: I3c343f0a7171891e106e709ca77ab9db5daa5c84
Reviewed-on: https://go-review.googlesource.com/c/go/+/328210
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
On ARM64, instruction like "MOVD (R1)(R2*1), R3" is accepted and
assembles correctly with Go 1.16, but errors out on tip with
"arm64 doesn't support scaled register format", since CL 289589.
"MOVD (R1)(R2), R3" is the preferred form. But the *1 form works
before and assembles correctly. Keep supporting it.
Fixes#46766.
Change-Id: I0f7fd71fa87ea698919a936b6c68aa5a91afd486
Reviewed-on: https://go-review.googlesource.com/c/go/+/328229
Trust: Cherry Mui <cherryyz@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: eric fang <eric.fang@arm.com>
For typed vs un-typed operation, the compiler do the conversion
un-conditionally, so if the operation is invalid, the error report is
pointed to the conversion, instead of the invalid operation itself.
To fix this, only do the conversion when the operations are valid
for both types.
Fixes#46749
Change-Id: Ib71c7bcd3ed5454e6df55b6a8db4e0f189259ba7
Reviewed-on: https://go-review.googlesource.com/c/go/+/328050
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: Matthew Dempsky <mdempsky@google.com>
Fix the problem that UTF8 BOM can cause the parsing of import path and directives to fail.
Fixes#46198Fixes#46290Fixes#35726
Change-Id: I2d9995ee82b094bcfa5583f0cb4e8547cb973077
GitHub-Last-Rev: 98abf91377
GitHub-Pull-Request: golang/go#46643
Reviewed-on: https://go-review.googlesource.com/c/go/+/325990
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
For internal linking, when generating a PIE binary, set the proper
.dynamic section flags to mark the binary as position-independent.
Fixes#46747.
Change-Id: I2b899148c6d06f92c9d12257a9761278b4236dfc
Reviewed-on: https://go-review.googlesource.com/c/go/+/328089
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
The windows/arm port does not yet support cgo, so disable a test that
requires it. This fixes a regression from CL 327969, which added support
for arm64, but errantly dropped the t.Skip for both arm and arm64,
rather than just for arm64. With this commit, we make the test specific
to cgo, rather than the architecture.
Change-Id: Ibe1166c1965e007c7af899b07ded65f2a2633ddd
Reviewed-on: https://go-review.googlesource.com/c/go/+/327970
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In CL 327210, we disabled this test on arm platforms, because the
powershell shipped with those systems isn't native, which means it'd
refuse to load native DLLs. This commit rewrites the test to simply not
use Powershell, and instead compiles a trivial C program that tests for
the same thing. Reverting CL 316269 makes this test fail, as desired,
while applying it makes this test succeed.
Fixes#46701
Change-Id: If39612c57bf74c63adf58e2c49b5cb739b461fe5
Reviewed-on: https://go-review.googlesource.com/c/go/+/327969
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Conversions of slices to arrays may panic since the slice is too short.
Comparibility of interfaces may panic since the underlying value is incomparable.
This is a follow-up to CL 301652
Change-Id: Ia5d84a6e556a7b82c39add4be93ed7463e63cc8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/327589
Trust: Joe Tsai <joetsai@digital-static.net>
Trust: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Some ET_EXEC binaries might have relocations for non-loadable sections
like .debug_info. These relocations must not be applied, because:
* They may be incorrect
* The correct relocations were already applied at link time
Binaries in Linux Kernel debug packages like Fedora/Centos kernel-debuginfo
are such examples. Relocations for .debug_* sections are included in the
final binaries because they are compiled with --emit-relocs, but the resulting
relocations are incorrect and shouldn't be used when reading DWARF sections.
Fixes#46673
Change-Id: I2b4214f1584bfc243446d0eaee41512657325b95
GitHub-Last-Rev: 8350fad059
GitHub-Pull-Request: golang/go#46698
Reviewed-on: https://go-review.googlesource.com/c/go/+/327009
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The comment use allg to refer to allgs in code. Update the comment to
use the same variable name.
Change-Id: Id059fce7846776737fb038b86bcf8765a4a7c9c0
GitHub-Last-Rev: 234fb0a208
GitHub-Pull-Request: golang/go#46723
Reviewed-on: https://go-review.googlesource.com/c/go/+/327629
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Consistently say "pointer to array", not "array pointer".
Fixes#46743
Change-Id: I2388ec5c16f96e82a3a383b9b462b350686ddc5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/327870
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The platform supports c-shared now, so flip this on. I've given this a
small smoke test using [1], and it was able to pass packets and
generally function well. Since [1] uses quite a bit of Go functionality
under the hood, I think it's a decent test that a lot of things that
should be working are working. So this commit enables it.
[1] https://git.zx2c4.com/wireguard-windows/about/embeddable-dll-service/README.md
Updates #46502.
Change-Id: I5c771d033bd20e5ce472c315d7c207bbc1020b4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/326310
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If any of the LHS expressions of an OAS2FUNC are not identical to the
respective function call results, escape analysis mishandles the
implicit conversion, causes memory corruption.
Instead, we should insert autotmps like we already do for f(g()) calls
and return g() statements.
Fixes#46725
Change-Id: I71a08da0bf1a03d09a023da5b6f78fb37a4a4690
Reviewed-on: https://go-review.googlesource.com/c/go/+/327651
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: Matthew Dempsky <mdempsky@google.com>
So next CL can reuse code to rewrite OAS2FUNC.
Passes toolstash -cmp.
For #46725
Change-Id: I1113ed615b6d6b9494dd87000ce342d7a46d9e7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/327650
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: Matthew Dempsky <mdempsky@google.com>
Clang does not produce binaries with an .edata section, even when it
exports symbols properly, so just skip this binutils-specific test for
that case. Later we can rewrite these tests entirely to do something
more robust.
Updates #46719.
Change-Id: I864b3c2d91e66800c55454ae11d4ab1623693d14
Reviewed-on: https://go-review.googlesource.com/c/go/+/327549
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 301650 adds conversion from slice to array ptr. The conversion
expression may appear as argument to a function call, so it will be
tested by mayCall. But ir.OSLICE2ARRPTR op is not handled by mayCall,
causes the compiler crashes.
Updates #395Fixes#46720
Change-Id: I39e1b3e38e224a31f3dec46dbbdc855ff3b2c6a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/327649
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Instead route through a C function, to avoid declaration conflicts
between the declaration needed in the cgo comment and the declaration
generated by cgo in _cgo_export.h.
This is not something user code will ever do, so no need to make it
work in cgo.
Fixes#46502
Change-Id: I1bfffdc76ef8ea63e3829871298d0774157957a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/327309
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 Mui <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
callMethod previously assumed erroneously that between the "value" and
"method" ABIs (that is, the ABI the caller is following to call this
method value and the actual ABI of the method), it could never happen
that an argument passed on the stack in the former could be passed in
registers in the latter. The cited reason was that the latter always
uses strictly more registers.
However, there are situations where the value ABI could pass a value on
the stack, but later is passed in a register. For instance, if the
receiver pushes a value passed in registers that uses multiple registers
to be passed on the stack, later arguments which were passed on the
stack may now be passed in registers.
This change fixes callMethod to no longer makes this assumption, and
handles the stack-to-register translation explicitly.
Fixes#46696.
Change-Id: I7100a664d97bbe401302cc893b3a98b28cdcdfc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/327089
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The powershell that currently ships on ARM Windows isn't native, so it
won't load native DLLs. So just skip the tests for now, and reenable it
if this ever changes.
Updates #46701.
Change-Id: I2559fdf13cb65d3ecdc4c6f6df7dec1b490b9651
Reviewed-on: https://go-review.googlesource.com/c/go/+/327210
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
Fixes#46466
Change-Id: I8fb15d0c8ef7ef6e6fc1b9e0e033d213255fe0df
Reviewed-on: https://go-review.googlesource.com/c/go/+/326778
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Fixes#46691
Change-Id: I3bef9a773be640bed96eb2dc395cb11671a0767a
Reviewed-on: https://go-review.googlesource.com/c/go/+/326869
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The net/http/internal package contains a PEM-encoded private key used in
tests. This key is initialized at init time, which prevents it from
being stripped by the linker in non-test binaries.
Move the certificate and key to a new net/http/internal/testcert
package to ensure it is only included in binaries that reference it.
Fixes#46677.
Change-Id: Ie98bda529169314cc791063e7ce4d99ef99113c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/326771
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Ideally we should encode the load.PackageInternal data in a way that
doesn't rely on 1:1 correlations of slices, but this is a minimal fix
to unblock Go 1.17.
Fixes#46462
Change-Id: I6e029c69f757aadc54d4be02c01d6b294c217542
Reviewed-on: https://go-review.googlesource.com/c/go/+/326610
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Explicitly document the handling of a sign prefix, and the interaction
between the sign and base prefixes.
Fixes#46641.
Change-Id: I3cd6773e3f074fe671a944a05a79d2408137fcd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/325875
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Semicolons are no longer valid separators, so
net/url.ParseQuery will now return an error
if any part of the query contains a semicolon.
net/http.(*Request).ParseMultipartForm has been
changed to fall through and continue parsing
even if the call to (*Request).ParseForm fails.
This change also includes a few minor refactors
to existing tests.
Fixes#25192
Change-Id: Iba3f108950fb99b9288e402c41fe71ca3a2ababd
Reviewed-on: https://go-review.googlesource.com/c/go/+/325697
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The comments in the code refer to Knuth and to Burnikel and Ziegler,
but Knuth's presentation is inscrutable, and our recursive division
code does not bear much resemblance to Burnikel and Ziegler's paper
(which is fine, ours is nicer).
Add a standalone explanation of division instead of referring to
difficult or not-directly-used references.
Change-Id: Ic1b35dc167fb29a69ee00e0b4a768ac9cc9e1324
Reviewed-on: https://go-review.googlesource.com/c/go/+/321078
Trust: Russ Cox <rsc@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The compiler machinery that generates "map.zero" symbols marks them as
RODATA and DUPOK, which is problematic when a given application has
multiple map zero symbols (from different packages) with varying
sizes: the dupok path in the loader assumes that if two symbols have
the same name, it is safe to pick any of the versions. In the case of
map.zero, the link needs to select the largest symbol, not an
arbitrary sym.
To fix this problem, mark map.zero symbols as content-addressable,
since the loader's content addressability processing path already
supports selection of the larger symbol in cases where there are dups.
Fixes#46653.
Change-Id: Iabd2feef01d448670ba795c7eaddc48c191ea276
Reviewed-on: https://go-review.googlesource.com/c/go/+/326211
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The linker's -strictdups debugging option was not properly checking
for cases where you have two dupok BSS symbols with different length
(the check examined data length and content, but not symbol size).
Updates #46653.
Change-Id: I3844f25ef76dd6e4a84ffd5caed5d19a1b1a57c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/326210
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This reverts CL 324471 (commit 689f4c7415).
Reason for revert: break ~all builders. And it is not a doc-only change.
Change-Id: Iadbdda34d2ca476a9f5e6c2d3a28592ed7ccb067
Reviewed-on: https://go-review.googlesource.com/c/go/+/326170
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
In both net.ParseIP and net.ParseCIDR reject leading zeros in the
dot-decimal notation of IPv4 addresses.
Fixes#30999Fixes#43389
Change-Id: I2b6a31fe84db89ac828cf5ed03eaa586ee96ab68
Reviewed-on: https://go-review.googlesource.com/c/go/+/325829
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
For interface types, t.Methods contains only unexpanded method set, i.e
exclusive of interface embedding. Thus, we can't use it to detect an
interface contains embedding empty interface, like in:
type EI interface{}
func f() interface{ EI } {
return nil
}
At the time we generate runtime types, we want to check against the full
method set of interface instead.
Fixes#46386
Change-Id: Idff53ad39276be6632eb5932b76e855c15cbdd2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/323649
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: Matthew Dempsky <mdempsky@google.com>
skipPleaseUseCallersFrames was removed in CL 152537.
Change-Id: Ide47feec85a33a6fb6882e16baf9e21492521640
Reviewed-on: https://go-review.googlesource.com/c/go/+/325949
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Fixes#46557
Change-Id: I95200ddd60e2879db15dd7353c2152b515c89020
Reviewed-on: https://go-review.googlesource.com/c/go/+/324909
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Previously we would sometimes return ErrRange if the parseable part of
the floating point number was out of range.
Fixes#46628
Change-Id: I15bbbb1e2a56fa27c19fe25ab5554d988cbfd9d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/325750
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is true since CL 315274.
Also adjust the P-256 note, since Add, Double, and IsOnCurve use the
generic, non-constant-time implementation.
Change-Id: I4b3b340f65bce91dcca30bcf86456cc8ce4dd4bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/325650
Trust: Filippo Valsorda <filippo@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The package-level documentation on fmt previously had only two formal
sections, for printing and scanning. Because of this, the section on
printing was very long, including some pseudo-sections describing
particular features. This feature makes those pseudo-sections into
proper sections, both to improve readability and so that those sections
have hyperlinks on documentation sites.
Fixes#46522
Change-Id: I38b7bc3447610faca446051da235edcbbd063f61
Reviewed-on: https://go-review.googlesource.com/c/go/+/324349
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
`io.ReadAll` dynamically reallocates byte slice because it doesn't know
its size in advance. We don't need to read an entire file into memory
and therefore may use `bufio.Reader` to read its contents.
Fixes#46564
Change-Id: Id504b1512662b6dea4775d523455896fa4162ab3
Reviewed-on: https://go-review.googlesource.com/c/go/+/325429
Reviewed-by: Dominik Honnef <dominik@honnef.co>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dominik Honnef <dominik@honnef.co>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
CL 249238 changes ResponseWriter.ReadFrom to probe the source with
a single read of sniffLen bytes before writing the response header.
If the source returns less than sniffLen bytes without reaching
EOF, this can cause Content-Type and Content-Length detection to
fail.
Fix ResponseWrite.ReadFrom to copy a full sniffLen bytes from
the source as a probe.
Drop the explicit call to w.WriteHeader; writing the probe will
trigger a WriteHeader call.
Consistently use io.CopyBuffer; ReadFrom has already acquired a
copy buffer, so it may as well use it.
Fixes#44953.
Change-Id: Ic49305fb827a2bd7da4764b68d64b797b5157dc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/301449
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If proc.Release is called concurrently, a handle will be double-freed.
Change-Id: I0c0c32e312e07bc8615e0bf9e9b691214444d8d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/322510
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We already have a handle to the process, so use that for termination,
rather than doing a new lookup based on the PID.
Change-Id: I2958c1817f12f3dd783412baacbf629049f6956a
Reviewed-on: https://go-review.googlesource.com/c/go/+/322509
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The declaration order in CL 319310 does not match what the generator
produces from scratch. That currently causes
cmd/internal/moddeps.TestAllDependencies to fail, since it is
explicitly checking for that kind of skew.
Updates #45914
Change-Id: If2a9cabc3d54e21deba7cb438fa364df205f38ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/325112
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
On Windows 7 (and below), console handles are not real kernel handles
but are rather userspace objects, with information passed via special
bits in the handle itself. That means they can't be passed in
PROC_THREAD_ATTRIBUTE_HANDLE_LIST, even though they can be inherited.
So, we filter the list passed to PROC_THREAD_ATTRIBUTE_HANDLE_LIST to
not have any console handles on Windows 7. At the same time, it turns
out that the presence of a NULL handle in the list is enough to render
PROC_THREAD_ATTRIBUTE_HANDLE_LIST completely useless, so filter these
out too. Console handles also can't be duplicated into parent processes,
as inhertance always happens from the present process, so duplicate
always into the present process even when a parent process is specified.
Fixes#45914.
Change-Id: I70b4ff4874dbf0507d9ec9278f63b9b4dd4f1999
Reviewed-on: https://go-review.googlesource.com/c/go/+/319310
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This CL updates cmd/compile (including types2) and go/types to report
errors about using unsafe.Add and unsafe.Slice when language
compatibility is set to Go 1.16 or older.
Fixes#46525.
Change-Id: I1bfe025a672d9f4b929f443064ad1effd38d0363
Reviewed-on: https://go-review.googlesource.com/c/go/+/324369
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
This ir.Dump call is a debugging artifact introduced in
golang.org/cl/274103, which should never be printed for valid,
non-generic code, but evidently can now sometimes appear due to how
the parser handles invalid syntax.
The parser should probably not recognize "x[2]" as a type expression
in non-generics mode, but also probably we shouldn't try noding after
reporting syntax errors. Either way, this diagnostic has outlived its
usefulness, and noder's days are numbered anyway, so we might as well
just remove it to save end users any confusion.
Updates #46558.
Change-Id: Ib68502ef834d610b883c2f2bb11d9b385bc66e37
Reviewed-on: https://go-review.googlesource.com/c/go/+/324991
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Set the correct section flags to insure that .debug_* sections are
using 1-byte alignment instead of the default. This seems to be
important for later versions of LLVM-mingw on windows (shows up on the
windows/arm64 builder).
Updates #46406.
Change-Id: I023d5208374f867552ba68b45011f7990159868f
Reviewed-on: https://go-review.googlesource.com/c/go/+/324763
Trust: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Following https://golang.org/cl/291329, exitsyscall0 accesses gp.lockedm
after releasing gp to the global runq. This creates a race window where
another M may schedule the (unlocked) G, which subsequently calls
LockOSThread, setting gp.lockedm and thus causing exitsyscall0 to think
it should call stoplockedm.
Avoid this race by checking if gp is locked before releasing it to the
global runq.
Fixes#46524
Change-Id: I3acdaf09e7a2178725adbe61e985130e9ebd0680
Reviewed-on: https://go-review.googlesource.com/c/go/+/324350
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Also don't unnecessarily deref the error return.
Fixes#46504
Change-Id: I22d14ac76776f8988fa0774bdcb5fcd801ce0185
Reviewed-on: https://go-review.googlesource.com/c/go/+/324190
Trust: David Chase <drchase@google.com>
Trust: Damien Neil <dneil@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
These tests pass or fail depending on the exact compiler version,
which the TestScript tests don't support. Rewrite into Go.
For #43830
For #46295
Change-Id: I91b61dfe329d518e461ee56f186f0e9b42858e77
Reviewed-on: https://go-review.googlesource.com/c/go/+/324049
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 Mui <cherryyz@google.com>
Fix up a gofmt complaint from CL 310591.
Change-Id: I73534ef064a4cfc53539e5e65a8653e2cd684c64
Reviewed-on: https://go-review.googlesource.com/c/go/+/324090
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This permits the test to work in C99 mode.
For #43830
Change-Id: Ide54bd62239cfe602e2664300f04e472df5daf43
Reviewed-on: https://go-review.googlesource.com/c/go/+/324009
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The linker now accepts unrecognized object files in external linking mode.
These objects will simply be passed to the external linker.
This permits using -flto which can generate pure byte code objects,
whose symbol table the linker does not know how to read.
The cgo tool now passes -fno-lto when generating objects whose symbols
it needs to read. The cgo tool now emits matching types in different
objects, so that the lto linker does not report a mismatch.
This is based on https://golang.org/cl/293290 by Derek Parker.
For #43505Fixes#43830Fixes#46295
Change-Id: I6787de213417466784ddef5af8899e453b4ae1ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/322614
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
When 'go get' updates a module, it may update another module in the
build list that provides a package in 'all' that wasn't loaded as part
of the 'go get' command. If 'go get' doesn't add a sum for that
module, builds may fail later.
With this change, 'go get' will fetch a sum for the content of an
updated module if we had a sum for the version before the update.
'go get' won't load the complete package graph, so there are still
cases where the build may be broken, like when an updated (but not
loaded) package imports a package from a new module.
Fixes#44129
Change-Id: I62eba3df4137a3e84e2ca8d549c36eec3670f08c
Reviewed-on: https://go-review.googlesource.com/c/go/+/322832
Trust: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Bryan C. Mills
Andy Pan
siddharth
Ian Lance Taylor
Xing Gao
Rob Findley
Daniel Theophanes
Derek Parker
Cherry Mui
Andrew G. Morgan
Nigel Tao
Matthew Dempsky
Michael Pratt
Tobias Klauser
Russ Cox
Cuong Manh Le
Rahul Bajaj
Filippo Valsorda
unbyte
Than McIntosh
Damien Neil
Jason A. Donenfeld
cuishuang
Joe Tsai
Victor Michel
Eric Wang
Michael Anthony Knyszek
Constantin Konstantinidis
Katie Hockman
Roland Shoemaker
Felix Geisendörfer
Branden J Brown
Sergey Zagursky
sryoya
Keith Randall
Vitaly Zdanevich
Jay Conrod