Russ Cox [Mon, 22 Jun 2020 17:27:10 +0000 (13:27 -0400)]
go/build: prefer //go:build over // +build lines
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
- Reject files with multiple //go:build lines.
- If a file has both //go:build and // +build lines, only use the //go:build line.
- Otherwise fall back to // +build lines
- Use go/build/constraint for parsing both //go:build and // +build lines.
For Go 1.17.
Change-Id: I32e2404d8ce266230f767718dc7cc24e77b425e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/240607
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Robert Griesemer [Wed, 17 Feb 2021 05:05:08 +0000 (21:05 -0800)]
spec: every type has a method set (minor clarification)
The spec states that a type "may" have a method set associated with it.
Yet every type has a method set, which may be empty. This is clarified
later in the same paragraph. Be clear in the first sentence as well.
Per the suggestion from https://github.com/DQNEO.
Fixes #44318.
Change-Id: I6097b1c7062853e404b7fead56d18a7f9c576fc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/292853
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Rob Findley [Fri, 19 Feb 2021 22:37:17 +0000 (17:37 -0500)]
go/types: don't write during sanitizeInfo if nothing has changed
In its final phase, the typechecker walks the types it produces to
ensure that no unexpanded type instances leak through the API. However,
this also walks shared types (such as those in the universe scope),
resulting in a potential data race during concurrent typechecking
passes.
Fix this by being careful not to write if nothing needs to be changed.
Since any shared types should already be sanitized, this should
eliminate data races.
For #44434
Change-Id: Iadb2e78863efe0e974e69a00e255f26cfaf9386a
Reviewed-on: https://go-review.googlesource.com/c/go/+/294411
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Dan Scales [Fri, 19 Feb 2021 02:07:09 +0000 (18:07 -0800)]
cmd/compile: fix check to avoid creating new closure function when typechecking inline body
By default, when typechecking a closure, tcClosure() creates a new
closure function. This should really be done separate from typechecking.
For now, we explicitly avoid creating a new closure function when
typechecking an inline body (in ImportedBody). However, the heuristic
for determining when we are typechecking an inline body was not correct
for double nested closures in an inline body, since CurFunc will then be
the inner closure, which has a body.
So, use a simple global variable to indicate when we typechecking an
inline body. The global variable is fine (just like ir.CurFunc), since
the front-end runs serially.
Fixes #44325
Change-Id: If2829fe1ebb195a7b1a240192b57fe6f04d1a36b
Reviewed-on: https://go-review.googlesource.com/c/go/+/294211
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Russ Cox [Fri, 19 Feb 2021 18:39:43 +0000 (13:39 -0500)]
codereview.cfg: add codereview.cfg for master branch
The codereview sync-branch command wants all involved
branches to have codereview.cfg, and this will help us when
we transition from master to main later this year.
Russ Cox [Fri, 19 Feb 2021 11:01:25 +0000 (06:01 -0500)]
runtime: ignore SPWRITE in syscall functions
netbsd/amd64's Syscall9 changes SP using ADD and SUB,
which are treated as SPWRITEs (they are not accounted for
in the sp-adjust tracking, and there are too many functions that
would report mismatched stack adjustments at RET if they were).
A traceback starting in Syscall9 as saved by entersyscall complains
about the SPWRITE-ness unnecessarily, since the PC/SP are saved
at the start of the function. Ignore SPWRITE in that case.
netbsd/arm's Syscall6 also changes SP (R13), using a direct write.
So even if we could handle the ADD/SUB in the amd64 case or
rewrote that assembly, we'd still be stuck with a more difficult
problem in this case. Ignoring the SPWRITE fixes it.
Russ Cox [Fri, 19 Feb 2021 10:42:20 +0000 (05:42 -0500)]
runtime/pprof: disable TestMorestack on macOS under race detector
This is failing but only under the race detector.
It doesn't really seem fair to expect pprof to find
specific profile events with the race detector slowing
everything down anyway.
Russ Cox [Fri, 19 Feb 2021 10:22:35 +0000 (05:22 -0500)]
runtime: fix spurious stack overflow detection
The regabi builders are unhappy about badctxt calling throw
calling systemstack calling gosave_systemstack_switch calling
badctxt, all nosplit, repeating. This wouldn't actually happen
since after one systemstack we'd end up on the system stack
and the next one wouldn't call gosave_systemstack_switch at all.
The badctxt call itself is in a very unlikely assertion failure
inside gosave_systemstack_switch.
Keep the assertion check but call runtime.abort instead on failure,
breaking the detected (but not real) cycle.
Than McIntosh [Wed, 17 Feb 2021 20:51:05 +0000 (15:51 -0500)]
cmd/compile: fix buglet in inlined info abstract function dwarf-gen
When generating DWARF inlined info records, it's possible to have a
local function whose only callsites are inlined away, meaning that we
emit an abstract function DIE but no regular subprogram DIE. When
emitting DWARF scope info we need to handle this case (specifically
when scoping PCs, check for the case that the func in question has
been entirely deleted).
Fixes #44344.
Change-Id: I9f5bc692f225aa4c5c23f7bd2e50bcf7fe4fc5f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/293309
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
An embedded struct field is embedded by mentioning its type.
The fact that the field name may be different and derived
from the type doesn't matter for the struct type.
Do print the embedded type rather than the derived field
name, as we have always done in the past. Remove the fancy
new code which was just plain wrong.
The struct output printing is only relevant for debugging
and test cases. Reverting to the original code (pre-generics)
fixes a couple of x/tools tests.
Unfortunately, the original code is (also) not correct for
embedded type aliases. Adjusted a gccgoimporter test
accordingly and filed issue #44410.
This is a follow-up on https://golang.org/cl/293961 which
addressed the issue only partially and left the incorrect
code in place.
Change-Id: Icb7a89c12ef7929c221fb1a5792f144f7fcd5855
Reviewed-on: https://go-review.googlesource.com/c/go/+/293962
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Rob Findley [Fri, 19 Feb 2021 01:08:42 +0000 (20:08 -0500)]
go/parser: improve error recovery from invalid selector exprs
Before this CL, the parser consumed the next token following an invalid
selector expr no matter what it was. This leads to poor error recovery
when this next token is a closing delimiter or other reasonable element
of a stop set. As a side-effect, x/tools tests broke when parser logic
for type parameters was introduced, as they threw off the parser
synchronization to the point where the x/tools test bailed out.
This CL introduces a targeted fix that allows the x/tools tests to pass.
More general improvement for parser error recovery should be done for
go1.17.
Change-Id: I44d73d34b6063e62d16a23d24ab7cbce6500239d
Reviewed-on: https://go-review.googlesource.com/c/go/+/293792
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Prior to 1.16, go/types printed an embedded struct field by simply
printing its type, which may have included a package qualification.
Just printing the type is not useful with generic types and we now
must print the actual field name derived from the type - this leads
to different output for non-generic imported embedded types. Fix by
printing a package qualification in that case.
Change-Id: I2cb2484da7732428d13fdfb5fe4ec1fa1ee813a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/293961
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Bryan C. Mills [Tue, 9 Feb 2021 20:38:18 +0000 (15:38 -0500)]
cmd/go/internal/mvs: split Reqs into narrower per-function interfaces
Reqs currently combines requirements with upgrades and downgrades.
However, only Upgrade needs the Upgrade method, and only Downgrade
needs the Previous method.
When we eventually add lazy loading, the lazily-loaded module graph
will not be able to compute upgrades and downgrades, so the
implementation work from here to there will be clearer if we are
explicit about which are still needed.
For #36460
Change-Id: I7bf8c2a84ce6bc4ef493a383e3d26850e9a6a6c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/290771
Trust: Bryan C. Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Bryan C. Mills [Thu, 4 Feb 2021 14:42:48 +0000 (09:42 -0500)]
cmd/go/internal/modget: split resolveCandidates into two methods
It turns out that the existing call sites of the resolveCandidates
method pass only *either* a slice of queries or a slice of upgrades
(never both), and the behaviors triggered by the two parameters don't
overlap much at all. To clarify the two different operations, split
them into two separate methods.
For #36460
Change-Id: I64651637734fd44fea68740a3cdfbacfb73c19b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/289697
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> Reviewed-by: Jay Conrod <jayconrod@google.com>
Russ Cox [Thu, 18 Feb 2021 16:47:47 +0000 (11:47 -0500)]
net: disable Windows netsh tests when netsh won't run
On my Surface Pro X running the insider preview,
running "netsh help" from Powershell started from the task bar works.
But running "powershell" at a cmd.exe prompt and then running
"netsh help" produces missing DLL errors.
These aren't our fault, so just skip the netsh-based tests if this happens.
Russ Cox [Mon, 15 Feb 2021 22:02:30 +0000 (17:02 -0500)]
runtime/pprof: expect tests to pass on macOS
macOS tests have been disabled since CL 12429045 (Aug 2013).
At the time, macOS required a kernel patch to get a working profiler
(https://research.swtch.com/macpprof), which we didn't want
to require, of course.
macOS has improved - it no longer requires the kernel patch - but
we never updated the list of exceptions.
As far as I can tell, the builders have no problem passing the pprof test now.
(It is possible that the iOS builders have trouble, but that is now a different GOOS.)
Remove the exception for macOS. The test should now pass.
Russ Cox [Thu, 11 Feb 2021 04:41:23 +0000 (23:41 -0500)]
math: remove most 387 implementations
The Surface Pro X's 386 simulator is not completely faithful to a real 387.
The most egregious problem is that it computes Log2(8) as 2.9999999999999996,
but it has some other subtler problems as well. All the problems occur in
routines that we don't even bother with assembly for on amd64.
If the speed of Go code is OK on amd64 it should be OK on 386 too.
Just remove all the 386-only assembly functions.
This leaves Ceil, Floor, Trunc, Hypot, and Sqrt in 386 assembly,
all of which are also in assembly on amd64 and all of which pass
their tests on Surface Pro X.
Compared to amd64, the 386 port omits assembly for Min, Max, and Log.
It never had Min and Max, and this CL deletes Log because Log2 wasn't
even correct. (None of the other architectures have assembly Log either.)
This CL adds a few small files - defs, os, and rt0 - to start
on windows/arm64 support for the runtime.
It also copies sys_windows_arm.s to sys_windows_arm64.s,
with the addition of "#ifdef NOT_PORTED" around the entire file.
This is meant to make future CLs easier to review, since the
general pattern is to translate the 32-bit ARM assembly into
64-bit ARM assembly.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I922037eb3890e77bac48281ecaa8e489595675be
Reviewed-on: https://go-review.googlesource.com/c/go/+/288827
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Russ Cox [Wed, 27 Jan 2021 02:14:43 +0000 (21:14 -0500)]
build: set GOPATH consistently in run.bash, run.bat, run.rc
We used to clear GOPATH in all the build scripts.
Clearing GOPATH is misleading at best, since you just end up
with the default GOPATH (%USERPROFILE%\go on Windows).
Unless that's your GOROOT, in which case you end up with a
fatal error from the go command (#43938).
run.bash changed to setting GOPATH=/dev/null, which has no
clear analogue on Windows.
run.rc still clears GOPATH.
Change them all to set GOPATH to a non-existent directory
/nonexist-gopath or c:\nonexist-gopath.
Change-Id: I51edd66d37ff6a891b0d0541d91ecba97fbbb03d
Reviewed-on: https://go-review.googlesource.com/c/go/+/288818
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Russ Cox [Wed, 27 Jan 2021 16:50:58 +0000 (11:50 -0500)]
cmd/link: clean up windows PE generation
A bunch of places are a bit too picky about the architecture.
Simplify them.
Also use a large PEBASE for 64-bit systems.
This more closely matches what is usually used on Windows x86-64
and is required for Windows arm64.
Unfortunately, we still need a special case for x86-64 because
of some cgo relocations. This may be fixable separately.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I65212d28ad4d8c40e2b70dc29f7fce072babecb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/288816
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Russ Cox [Wed, 27 Jan 2021 16:39:48 +0000 (11:39 -0500)]
syscall: clean up windows a bit
The files being deleted contain no code.
They exist because back when we used Makefiles
that listed all the Go sources to be compiled, we wrote
patterns like syscall_$GOOS_$GOARCH.go,
and it was easier to create dummy empty files
than introduce conditionals to not look for that
file on Windows.
Now that we have the go command instead,
we don't need those dummy files.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: Ie0066d1dd2bf09802c74c6a496276e8c593e4bc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/288815
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Russ Cox [Wed, 27 Jan 2021 16:34:42 +0000 (11:34 -0500)]
runtime: enable framepointer on all arm64
Frame pointers were already enabled on linux, darwin, ios,
but not freebsd, android, openbsd, netbsd.
But the space was reserved on all platforms, leading to
two different arm64 framepointer conditions in different
parts of the code, one of which had no name
(framepointer_enabled || GOARCH == "arm64",
which might have been "framepointer_space_reserved").
So on the disabled systems, the stack layouts were still
set up for frame pointers and the only difference was not
actually maintaining the FP register in the generated code.
Reduce complexity by just enabling the frame pointer
completely on all the arm64 systems.
This commit passes on freebsd, android, netbsd.
I have not been able to try it on openbsd.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Russ Cox [Thu, 28 Jan 2021 14:23:35 +0000 (09:23 -0500)]
runtime: clean up windows a bit
Document the various hard-coded architecture checks
or remove them in favor of more general checks.
This should be a no-op now but will make the arm64 port
have fewer diffs.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Russ Cox [Wed, 27 Jan 2021 16:27:25 +0000 (11:27 -0500)]
runtime: fix windows/arm externalthreadhandler
Externalthreadhandler was not handling its own stack correctly.
It incorrectly referred to the saved LR slot (uninitialized, it turned out)
as holding the return value from the called function.
Externalthreadhandler is used to call two different functions:
profileloop1 and ctrlhandler1.
Profileloop1 does not return, so no harm done.
Ctrlhandler1 returns a boolean indicating whether the handler
took care of the control event (if true, no other handlers run).
It's hard to say exactly what uninitialized values are likely to
have been returned instead of ctrlhandler1's result, but it
probably wasn't helping matters.
Change-Id: Ia02f1c033df618cb82c2193b3a8241ed048a8b18
Reviewed-on: https://go-review.googlesource.com/c/go/+/288812
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Russ Cox [Wed, 27 Jan 2021 16:22:02 +0000 (11:22 -0500)]
runtime: fix time on windows/arm under WINE
This code has clearly never run successfully,
since one of the “tail calls" calls the wrong function,
and both of them appear in functions with stack frames
that are never going to be properly unwound.
Probably there is no windows/arm under WINE at all.
But might as well fix the code.
Change-Id: I5fa62274b3661bc6bce098657b5bcf11d59655eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/288811
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Russ Cox [Wed, 27 Jan 2021 16:15:33 +0000 (11:15 -0500)]
runtime: crash earlier on windows for runtime.abort
The isAbort check was wrong for non-x86 systems.
That was causing the exception chain to be passed back to Windows.
That was causing some other kind of fault - not sure what.
That was leading back to lastcontinuehandler to print a larger
stack trace, and then the throwing = 1 print added runtime.abort,
which made TestAbort pass even though it wasn't really working.
Recognize abort properly and handle it as Go, not as something
for Windows to try to handle.
Keep the throwing = 1 print, because more detail on throw is
always better.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Russ Cox [Wed, 27 Jan 2021 02:26:01 +0000 (21:26 -0500)]
runtime: print hex numbers with hex prefixes in traceback debug
If traceback fails, it prints a helpful hex dump of the stack.
But the hex numbers have no 0x prefix, which might make it
a little unclear that they are hex.
We only print two per line, so there is plenty of room for the 0x.
Print it, which lets us delete a custom hex formatter.
Also, in the translated <name+off> hints, print off in hex
(with a 0x prefix). The offsets were previously decimal, which
could have been confused for hex since none of the hex had
0x prefixes. And decimal is kind of useless anyway since the
offsets shown in the main traceback are hex, so you can't
easily match them up without mental base conversions.
Just print hex everywhere, clearly marked by 0x.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Russ Cox [Wed, 27 Jan 2021 16:02:33 +0000 (11:02 -0500)]
runtime: fix windows/arm CONTEXT_CONTROL
The constant was wrong, and the “right” constant doesn't work either.
But with the actually-right constant (and possibly earlier fixes in this
stack as well), profiling now works.
Change-Id: If8caff1da556826db40961fb9bcfe2b1f31ea9f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/288808
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Russ Cox [Wed, 27 Jan 2021 16:01:00 +0000 (11:01 -0500)]
runtime: factor common code out of defs_windows_*.go
Also give up on the fiction that these files can be regenerated.
They contain many manual edits, and they're fairly small anyway.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: Ib4e4e20a43d8beb1d5390fd184160c33607641f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/288807
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Russ Cox [Wed, 27 Jan 2021 16:06:04 +0000 (11:06 -0500)]
runtime: find g in Windows profiler using SP
The architecture-specific interpretation of m->tls[0]
is unnecessary and fragile. Delete it.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I927345e52fa2f1741d4914478a29d1fb8acb0dc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/288806
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Russ Cox [Fri, 29 Jan 2021 14:55:03 +0000 (09:55 -0500)]
runtime: do not treat asmcgocall as a topofstack on g0
This was added in 2018 to fix a runtime crash during unwind
during a unhandled-panic-induced crash.
(See https://golang.org/cl/90895 and #23576.)
Clearly we cannot unwind past this function, and the change
did stop the unwind. But it's not a top-of-stack function, and
the real issue is that SP is changed.
The new SPWRITE bit takes care of this instead, so we can drop
it from the topofstack function.
At this point the topofstack function is only checking the
TOPFRAME bit, so we can inline that into the one call site.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Russ Cox [Fri, 29 Jan 2021 14:05:10 +0000 (09:05 -0500)]
runtime: do not treat morestack as a topofstack
I added morestack to this list in 2013 with an explanation
that they were needed if we “start a garbage collection on g0
during a stack split or unsplit”.
(https://golang.org/cl/11533043)
This explanation no longer applies for a handful of reasons,
most importantly that if we did stop a stack scan in the middle
of a call to morestack, we'd ignore pointers above the split,
which would lead to memory corruption. But we don't scan
goroutine stacks during morestack now, so that can't happen.
If we did see morestack during a GC, that would be a good time
to crash the program.
The real problem with morestack is during profiling, as noted
in the code review conversation during 2013. And in profiling
we just need to know to stop and not unwind further, which
the new SPWRITE bit will do for us.
So remove from topofstack and let the program crash if GC
sees morestack and otherwise let the SPWRITE stop morestack
unwinding during profiling.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Russ Cox [Thu, 28 Jan 2021 22:17:38 +0000 (17:17 -0500)]
runtime: do not treat mcall as a topofstack
I added mcall to this list in 2013 without explaining why.
(https://codereview.appspot.com/11085043/diff/61001/src/pkg/runtime/traceback_x86.c)
I suspect I was stopping crashes during profiling where the unwind
tried to walk up past mcall and got confused.
mcall is not something you can unwind past, because it switches
stacks, but it's also not something you should expect as a
standard top-of-stack frame. So if you do see it during say
a garbage collection stack walk, it would be important to crash
instead of silently stopping the walk prematurely.
This CL removes it from the topofstack list to avoid the silent stop.
Now that mcall is detected as SPWRITE, that will stop the
unwind (with a crash if encountered during GC, which we want).
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Russ Cox [Thu, 28 Jan 2021 21:22:52 +0000 (16:22 -0500)]
runtime: use TOPFRAME to identify top-of-frame functions
No change to actual runtime, but helps reduce the laundry list
of functions.
mcall, morestack, and asmcgocall are not actually top-of-frame,
so those need more attention in follow-up CLs.
mstart moved to assembly so that it can be marked TOPFRAME.
Since TOPFRAME also tells DWARF consumers not to unwind
this way, this change should also improve debuggers a
marginal amount.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Russ Cox [Thu, 28 Jan 2021 21:10:58 +0000 (16:10 -0500)]
runtime: use FuncInfo SPWRITE flag to identify untraceable profile samples
The old code was very clever about predicting whether a traceback was safe.
That cleverness has not aged well. In particular, the setsSP function is missing
a bunch of functions that write to SP and will confuse traceback.
And one such function - jmpdefer - was handled as a special case in
gentraceback instead of simply listing it in setsSP.
Throw away all the clever prediction about whether traceback will crash.
Instead, make traceback NOT crash, by checking whether the function
being walked writes to SP.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Russ Cox [Thu, 28 Jan 2021 20:21:33 +0000 (15:21 -0500)]
cmd/asm, cmd/link, runtime: introduce FuncInfo flag bits
The runtime traceback code has its own definition of which functions
mark the top frame of a stack, separate from the TOPFRAME bits that
exist in the assembly and are passed along in DWARF information.
It's error-prone and redundant to have two different sources of truth.
This CL provides the actual TOPFRAME bits to the runtime, so that
the runtime can use those bits instead of reinventing its own category.
This CL also adds a new bit, SPWRITE, which marks functions that
write directly to SP (anything but adding and subtracting constants).
Such functions must stop a traceback, because the traceback has no
way to rederive the SP on entry. Again, the runtime has its own definition
which is mostly correct, but also missing some functions. During ordinary
goroutine context switches, such functions do not appear on the stack,
so the incompleteness in the runtime usually doesn't matter.
But profiling signals can arrive at any moment, and the runtime may
crash during traceback if it attempts to unwind an SP-writing frame
and gets out-of-sync with the actual stack. The runtime contains code
to try to detect likely candidates but again it is incomplete.
Deriving the SPWRITE bit automatically from the actual assembly code
provides the complete truth, and passing it to the runtime lets the
runtime use it.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I227f53b23ac5b3dabfcc5e8ee3f00df4e113cf58
Reviewed-on: https://go-review.googlesource.com/c/go/+/288800
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Russ Cox [Mon, 15 Feb 2021 14:25:55 +0000 (09:25 -0500)]
runtime: remove unnecessary writes to gp.sched.g
A g's sched.g is set in newproc1:
newg.sched.g = guintptr(unsafe.Pointer(newg))
After that, it never changes. Yet lots of assembly code does
"g.sched.g = g" unnecessarily. Remove all those lines to avoid
confusion about whether it ever changes.
Also, split gogo into two functions, one that does the nil g check
and a second that does the actual switch. This way, if the nil g check
fails, we get a stack trace showing the call stack that led to the failure.
(The SP write would otherwise cause the stack trace to abort.)
Also restore the proper nil g check in a handful of assembly functions.
(There is little point in checking for nil g *after* installing it as the real g.)
Russ Cox [Tue, 2 Feb 2021 03:58:28 +0000 (22:58 -0500)]
runtime: unify asmcgocall and systemstack traceback setup
Both asmcgocall and systemstack need to save the calling Go code's
context for use by traceback, but they do it differently.
Systemstack's appraoch is better, because it doesn't require a
special case in traceback.
So make them both use that.
While we are here, the fake mstart caller in systemstack is
no longer needed and can be removed.
(traceback knows to stop in systemstack because of the writes to SP.)
Also remove the fake mstarts in sys_windows_*.s.
And while we are there, fix the control flow guard code in sys_windows_arm.s.
The current code is using pointers to a stack frame that technically is gone
once we hit the RET instruction. Clearly it's working OK, but better not to depend
on data below SP being preserved, even for just a few instructions.
Store the value we need in other registers instead.
(This code is only used for pushing a sigpanic call, which does not
actually return to the site of the fault and therefore doesn't need to
preserve any of the registers.)
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Russ Cox [Thu, 28 Jan 2021 14:32:55 +0000 (09:32 -0500)]
runtime: clean up funcID assignment
Large enum sets should be sorted by name when the
values don't matter, as they don't here. Do that.
Also replace the large switch with a map lookup.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: Ibe727b5d8866bf4c40c96020e1f4632bde7efd59
Reviewed-on: https://go-review.googlesource.com/c/go/+/288798
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Wed, 27 Jan 2021 16:00:21 +0000 (11:00 -0500)]
runtime: handle nil gp in cpuprof
This can happen on Windows when recording profile samples for system threads.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I5a7ba32b1900a69f3b7acada9cb6cf8396d8a03f
Reviewed-on: https://go-review.googlesource.com/c/go/+/288797
Trust: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Wed, 27 Jan 2021 15:47:38 +0000 (10:47 -0500)]
runtime: move sys.DefaultGoroot to runtime.defaultGOROOT
The default GOROOT has nothing to do with system details.
Move it next to its one use in package runtime.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I1a601fad6335336b4616b834bb21bd8437ee1313
Reviewed-on: https://go-review.googlesource.com/c/go/+/288796
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Russ Cox [Wed, 27 Jan 2021 06:06:52 +0000 (01:06 -0500)]
runtime: document, clean up internal/sys
Document what the values in internal/sys mean.
Remove various special cases for arm64 in the code using StackAlign.
Delete Uintreg - it was for GOARCH=amd64p32,
which was specific to GOOS=nacl and has been retired.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I40e8fa07b4e192298b6536b98a72a751951a4383
Reviewed-on: https://go-review.googlesource.com/c/go/+/288795
Trust: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Sat, 30 Jan 2021 21:18:51 +0000 (16:18 -0500)]
runtime: delete windows setlasterror (unused)
This is dead code and need not be ported to each architecture.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I2d0072b377f73e49d7158ea304670c26f5486c59
Reviewed-on: https://go-review.googlesource.com/c/go/+/288794
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Russ Cox [Sat, 30 Jan 2021 12:07:42 +0000 (07:07 -0500)]
runtime: clean up system calls during cgo callback init
During a cgocallback, the runtime calls needm to get an m.
The calls made during needm cannot themselves assume that
there is an m or a g (which is attached to the m).
In the old days of making direct system calls, the only thing
you had to do for such functions was mark them //go:nosplit,
to avoid the use of g in the stack split prologue.
But now, on operating systems that make system calls through
shared libraries and use code that saves state in the g or m
before doing so, it's not safe to assume g exists. In fact, it is
not even safe to call getg(), because it might fault deferencing
the TLS storage to find the g pointer (that storage may not be
initialized yet, at least on Windows, and perhaps on other systems
in the future).
The specific routines that are problematic are usleep and osyield,
which are called during lock contention in lockextra, called
from needm.
All this is rather subtle and hidden, so in addition to fixing the
problem on Windows, this CL makes the fact of not running on
a g much clearer by introducing variants usleep_no_g and
osyield_no_g whose names should make clear that there is no g.
And then we can remove the various sketchy getg() == nil checks
in the existing routines.
As part of this cleanup, this CL also deletes onosstack on Windows.
onosstack is from back when the runtime was implemented in C.
It predates systemstack but does essentially the same thing.
Instead of having two different copies of this code, we can use
systemstack consistently. This way we need not port onosstack
to each architecture.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I3352de1fd0a3c26267c6e209063e6e86abd26187
Reviewed-on: https://go-review.googlesource.com/c/go/+/288793
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Russ Cox [Sat, 30 Jan 2021 12:27:24 +0000 (07:27 -0500)]
os: report Windows exit status in hex
We print things like “exit status 3221225477”
but the standard Windows form is 0xc0000005.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: Iefe447d4d1781b53bef9619f68d386f2866b2934
Reviewed-on: https://go-review.googlesource.com/c/go/+/288792
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Thu, 18 Feb 2021 23:09:38 +0000 (15:09 -0800)]
[dev.typeparams] cmd/compile: use new converter functions rather than methods (fix build)
Change-Id: I4dcaca1f2e67ee32f70c22b2efa586232ca519bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/293958
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Dan Scales [Thu, 11 Feb 2021 18:50:20 +0000 (10:50 -0800)]
[dev.typeparams] cmd/compile: support generic types (with stenciling of method calls)
A type may now have a type param in it, either because it has been
composed from a function type param, or it has been declared as or
derived from a reference to a generic type. No objects or types with
type params can be exported yet. No generic type has a runtime
descriptor (but will likely eventually be associated with a dictionary).
types.Type now has an RParam field, which for a Named type can specify
the type params (in order) that must be supplied to fully instantiate
the type. Also, there is a new flag HasTParam to indicate if there is
a type param (TTYPEPARAM) anywhere in the type.
An instantiated generic type (whether fully instantiated or
re-instantiated to new type params) is a defined type, even though there
was no explicit declaration. This allows us to handle recursive
instantiated types (and improves printing of types).
To avoid the need to transform later in the compiler, an instantiation
of a method of a generic type is immediately represented as a function
with the method as the first argument.
Added 5 tests on generic types to test/typeparams, including list.go,
which tests recursive generic types.
Change-Id: Ib7ff27abd369a06d1c8ea84edc6ca1fd74bbb7c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/292652
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
Robert Griesemer [Thu, 18 Feb 2021 22:35:08 +0000 (14:35 -0800)]
[dev.typeparams] all: merge master (eb98272) into dev.typeparams
Merge List:
+ 2021-02-18 eb982727e3 cmd/go/internal/mvs: fix Downgrade to match Algorithm 4
+ 2021-02-18 3b7277d365 cmd/go: add a script test for artifacts resulting from 'go get -u'
+ 2021-02-18 f3c2208e2c cmd/go: add script tests for potential upgrades due to downgrades
+ 2021-02-18 a5c8a15f64 cmd/go/internal/mvs: clarify and annotate test cases
+ 2021-02-18 a76efea1fe cmd/go/internal/mvs: don't emit duplicates from Req
+ 2021-02-18 609d82b289 cmd/dist: set GOARM=7 for windows/arm
+ 2021-02-18 f0be3cc547 runtime: unbreak linux/riscv64 following regabi merge
+ 2021-02-18 07ef313525 runtime/cgo: add cast in C code to avoid C compiler warning
Bryan C. Mills [Thu, 28 Jan 2021 14:10:57 +0000 (09:10 -0500)]
cmd/go/internal/mvs: fix Downgrade to match Algorithm 4
mvs.Downgrade is pretty clearly intended to match Algorithm 4 from the
MVS blog post (https://research.swtch.com/vgo-mvs#algorithm_4).
Per the blog post:
“Downgrading one module may require downgrading other modules, but we
want to downgrade as few other modules as possible. … To avoid an
unnecessary downgrade to E 1.1, we must also add a new requirement on
E 1.2. We can apply Algorithm R to find the minimal set of new
requirements to write to go.mod.”
mvs.Downgrade does not match that behavior today: it fails to retain
the selected versions of transitive dependencies that are not implied
by downgraded direct dependencies of the target (module E in the
post). This bug is currently masked by the fact that we only call
Downgrade today with a *modload.mvsReqs, for which the Required method
happens to return the complete build list — rather than only the
direct dependencies as documented for the mvs.Reqs interface.
For #36460
Change-Id: If9c8f413b156b5f67c02787d9359394e169951b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/287633
Trust: Bryan C. Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Robert Griesemer [Thu, 18 Feb 2021 05:42:36 +0000 (21:42 -0800)]
[dev.typeparams] cmd/compile/internal/types: review of typestring_test.go
The changes between (equivalent, and reviewed) go/types/typestring_test.go
and typestring_test.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: I66150c0ab738763d2d8b94483ef8314cbe28a374
Reviewed-on: https://go-review.googlesource.com/c/go/+/293473
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Robert Griesemer [Thu, 18 Feb 2021 05:31:41 +0000 (21:31 -0800)]
[dev.typeparams] cmd/compile/internal/types: review of typestring.go
The changes between (equivalent, and reviewed) go/types/typestring.go
and typestring.go can be seen by comparing patchset 1 and 3. The actual
change is just removing the "// UNREVIEWED" marker plus an adjustment
to writeTParamList (we now always write type constraints).
Change-Id: Ieb109c17756addc954e1ca0da606fa5b335ff30d
Reviewed-on: https://go-review.googlesource.com/c/go/+/293472
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Robert Griesemer [Thu, 18 Feb 2021 05:18:07 +0000 (21:18 -0800)]
[dev.typeparams] cmd/compile/internal/types: review of type.go
The changes between (equivalent, and reviewed) go/types/type.go
and type.go can be seen by comparing patchset 1 and 3. The actual
change is just removing the "// UNREVIEWED" marker and some
comment adjustments.
Change-Id: Ied0e2f942bc96a9fcae0466761cfaa60a87668db
Reviewed-on: https://go-review.googlesource.com/c/go/+/293471
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Robert Griesemer [Thu, 18 Feb 2021 01:56:34 +0000 (17:56 -0800)]
[dev.typeparams] cmd/compile/internal/types2: remove Type.Under method in favor of function
This removes the need for the aType embedded type and brings the types2.Type
API in sync with the go/types.Type API.
For reasons not fully understood yet, introducing the new under function
causes a very long initialization cycle error, which doesn't exist in
go/types. For now, circumvent the problem through a helper function variable.
This CL also eliminates superflous (former) Under() method calls
inside optype calls (optype takes care of this).
Plus some minor misc. cleanups and comment adjustments.
Change-Id: I86e13ccf6f0b34d7496240ace61a1c84856b6033
Reviewed-on: https://go-review.googlesource.com/c/go/+/293470 Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Robert Griesemer [Thu, 18 Feb 2021 01:06:53 +0000 (17:06 -0800)]
[dev.typeparams] cmd/compile/internal/types2: replace Named, TypeParam methods with functions
This removes two more converter methods in favor of functions.
This further reduces the API surface of types2.Type and matches
the approach taken in go/types.
Change-Id: I3cdd54c5e0d1e7664a69f3697fc081a66315b969
Reviewed-on: https://go-review.googlesource.com/c/go/+/293292
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Robert Griesemer [Thu, 18 Feb 2021 00:04:59 +0000 (16:04 -0800)]
[dev.typeparams] cmd/compile/internal/types2: use converter functions rather than methods
This change replaces methods with functions to reduce the API surface of
types2.Type and to match the approach taken in go/types. The converter
methods for Named and TypeParam will be addressed in a follow-up CL.
Also: Fixed behavior of optype to return the underlying type for
arguments that are not type parameters.
Change-Id: Ia369c796754bc33bbaf0c9c8478badecb729279b
Reviewed-on: https://go-review.googlesource.com/c/go/+/293291
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Rob Findley [Wed, 17 Feb 2021 00:56:38 +0000 (19:56 -0500)]
[dev.typeparams] go/types: use a new ast.ListExpr for multi-type instances
Modify go/parser to consistently represent type instantiation as an
ast.IndexExpr, rather than use an ast.CallExpr (with Brackets:true) for
instantiations with multiple type parameters. To enable this, introduce
a new ast expr type: ListExpr.
This brings go/types in line with types2, with the exception of a small
change to funcInst to eliminate redundant errors if values are
erroneously used as types. In a subsequent CL, call.go and expr.go will
be marked as reviewed.
This also catches some type instance syntax using '()' that was
previously accepted incorrectly. Tests are updated accordingly.
Change-Id: I30cd0181c7608f1be7486a9a8b63df993b412e85
Reviewed-on: https://go-review.googlesource.com/c/go/+/293010
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>
Bryan C. Mills [Thu, 28 Jan 2021 15:18:24 +0000 (10:18 -0500)]
cmd/go/internal/mvs: don't emit duplicates from Req
Req is supposed to return “a minimal requirement list”
that includes each of the module paths listed in base.
Currently, if base contains duplicates Req emits duplicates,
and a list containing duplicates is certainly not minimal.
That, in turn, requires callers to be careful to deduplicate the base
slice, and there are multiple callers that are already quite
complicated to reason about even without the added complication of
deduplicating slices.
For #36460
Change-Id: I391a1dc0641fe1dd424c16b7a1082da0d00c7292
Reviewed-on: https://go-review.googlesource.com/c/go/+/287632
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> Reviewed-by: Jay Conrod <jayconrod@google.com>
Jason A. Donenfeld [Fri, 12 Feb 2021 20:34:11 +0000 (21:34 +0100)]
cmd/dist: set GOARM=7 for windows/arm
GOARM=6 executables fail to launch on windows/arm, so set this to ARMv7
like we do for Android.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: Ifa13685e7ab6edd367f3dfec10296e376319dbd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/291629 Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Rob Findley [Thu, 11 Feb 2021 16:54:46 +0000 (11:54 -0500)]
[dev.typeparams] go/types: conversions to type parameters are not constant
This is a port of CL 290471 to go/types. However, this change preserves
the existing check for constant types in recordTypeAndValue, which uses
is(..., isConstType) rather than the isConstType predicate. In types2,
this code path is not hit with type parameters because convertUntyped
walks the type list in order before calling updateExprType with the type
parameter, at which point the expression type would have already been
recorded as the first element of the type list -- probably something
that should be corrected.
Longer term, I believe we actually could allow const type parameters if
the optype is a sum of constant types.
Change-Id: Iaa91ffa740b5f08a5696bd96918a866bffd7aef6
Reviewed-on: https://go-review.googlesource.com/c/go/+/291323
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>
Joel Sing [Wed, 17 Feb 2021 09:34:34 +0000 (20:34 +1100)]
runtime: unbreak linux/riscv64 following regabi merge
Unbreak the linux/riscv64 port by storing the zero value register to memory,
rather than the current code that is moving a zero intermediate to the stack
pointer register (ideally this should be caught by the assembler). This was
broken in CL#272568.
On riscv64 a zero immediate value cannot be moved directly to memory, rather
a register needs to be loaded with zero and then stored. Alternatively, the
the zero value register (aka X0) can be used directly.
Change-Id: Id57121541d50c9993cec5c2270b638b184ab9bc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/292894
Trust: Joel Sing <joel@sing.id.au> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Ian Lance Taylor [Wed, 17 Feb 2021 20:03:13 +0000 (12:03 -0800)]
runtime/cgo: add cast in C code to avoid C compiler warning
Fixes #44340
Change-Id: Id80dd1f44a988b653933732afcc8e49a826affc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/293209 Reviewed-by: Andrew G. Morgan <agm@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Rob Findley [Wed, 17 Feb 2021 21:34:00 +0000 (16:34 -0500)]
[dev.typeparams] merge master (2f0da6d) into dev.typeparams
This was a mostly clean merge, with the exception of codereview.cfg and
changes in src/go/types.
codereview.cfg for dev.typeparams is preserved in this CL. It should be
deleted before merging back to master.
The go/types changes were merged manually. For the most part this
involved taking the union of patches, with the following exceptions:
+ declInfo.aliasPos is removed, as it is not necessary in
dev.typeparams where we have access to the full TypeSpec.
+ Checker.overflow is updated to use the asBasic converter.
+ A TODO is added to errorcodes.go to ensure that go1.16 error codes
are preserved.
Dan Scales [Wed, 17 Feb 2021 02:24:48 +0000 (18:24 -0800)]
[dev.typeparams] cmd/dist: disable -G=3 on the std go tests for now
Disable -G=3 tests on the std go tests, in order to see if -G=3 is
causing the flakiness for the dev.typeparams builder, as opposed to
other changes in typeparams branch. It's possible that -G=3 is using
more CPU/RAM that causes flakiness, as opposed to more specific bugs.
Change-Id: I610bce2aabd26b2b1fddc5e63f85ffe4e958e0d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/292850
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
Rob Findley [Wed, 17 Feb 2021 01:01:32 +0000 (20:01 -0500)]
go/types: revert "no 'declared but not used' errors for invalid var decls"
This reverts commit CL 289712 (afd67f3). It breaks x/tools tests, and
those tests highlight that perhaps I didn't think through the
repercussions of this change as much as I should have.
Fixes #44316
Change-Id: I5db39b4e2a3714131aa22423abfe0f34a0376192
Reviewed-on: https://go-review.googlesource.com/c/go/+/292751 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Cherry Zhang [Tue, 16 Feb 2021 21:55:30 +0000 (16:55 -0500)]
all: merge branch dev.regabi (d3cd4830ad) into master
This CL merges the dev.regabi branch to the master branch.
In the dev.regabi branch we have refactored the compiler, and laid
some preliminary work for enabling a register-based ABI (issue #40724),
including improved late call/return lowering, improved ABI wrapper
generation, reflect call prepared for the new ABI, and reserving
special registers in the internal ABI. The actual register-based ABI
has not been enabled for the moment. The ABI-related changes are behind
GOEXPERIMENT=regabi and currently off by default.
Cherry Zhang [Fri, 12 Feb 2021 00:55:07 +0000 (19:55 -0500)]
[dev.regabi] test: run abi/regabipragma test with -c=1
Currently, we call Warnl in SSA backend when we see a function
(defined or called) with regparams pragma. Calling Warnl in
concurrent environment is racy. As the debugging output is
temporary, for testing purposes we just pass -c=1. We'll remove
the pragma and the debugging print some time soon.
Change-Id: I6f925a665b953259453fc458490c5ff91f67c91a
Reviewed-on: https://go-review.googlesource.com/c/go/+/291710
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jeremy Faller <jeremy@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Change-Id: I28c42727735f467a5984594b455ca58ab3375591
Reviewed-on: https://go-review.googlesource.com/c/go/+/291319
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>
Rob Findley [Thu, 11 Feb 2021 15:45:49 +0000 (10:45 -0500)]
[dev.regabi] go/types: type alias decl requires go1.9
This is a port of CL 289570 to go/types. It has some notable differences
with that CL:
+ A new _BadDecl error code is added, to indicate declarations with bad
syntax.
+ declInfo is updated hold not an 'alias' bool, but an aliasPos
token.Pos to identify the location of the type aliasing '=' token.
This allows for error messages to be accurately placed on the '='
For #31793
Change-Id: Ib15969f9cd5be30228b7a4c6406f978d6fc58018
Reviewed-on: https://go-review.googlesource.com/c/go/+/291318
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>