This sets up for introducing the 'go' and 'toolchain' modules
but should be a no-op by itself.
For #57001.
Change-Id: I2e02b5d417f1edd4f4653b101e4975fe23093f66
Reviewed-on: https://go-review.googlesource.com/c/go/+/497456
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Now that cfg.CanGetenv does the right thing, we don't need a separate
readEnvFile in 'go env'.
Change-Id: I187c8615ad074ba132516bcf499f82877a32d5e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/497457
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
As part of the work for #57179 we moved configurable defaults
to GOROOT/go.env, so that packagers don't have to modify
source code to change those defaults. Since packagers may want
to modify GOTOOLCHAIN's default, move it to go.env too.
This CL modifies 'go env' to print GOTOOLCHAIN by default.
It also refines CL 496957 from yesterday to recognize any env
var in either go.env or the user go/env, not just the user go/env.
When I put GOTOOLCHAIN in go.env, but before I added it to
the default printing list, 'go env GOTOOLCHAIN' was printing
an empty string, and it was incredibly confusing.
For #57001.
Fixes#60361 while we're here.
Also includes a fix for a review comment on CL 497079 that I forgot to mail.
Change-Id: I7b904d9202f05af789aaa33aed93f903b515aa28
Reviewed-on: https://go-review.googlesource.com/c/go/+/497437
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reapples CL 495596, which was reverted at CL 496185. The x/tools
failure, #60263, has been resolved. The ppc64 failures, #60368, have
_not_ been resolved, but are believed to be specific to that port. This
CL will make ppc64 flaky while the issue is investigated, but give more
soak time on primary ports.
Build the compiler with PGO. As go build -pgo=auto is enabled by
default, we just need to store a profile in the compiler's
directory.
The profile is collected from building all std and cmd packages on
Linux/AMD64 machine, using profile.sh.
This improves the compiler speed. On Linux/AMD64,
name old time/op new time/op delta
Template 138ms ± 5% 136ms ± 4% -1.44% (p=0.005 n=36+39)
Unicode 147ms ± 4% 140ms ± 4% -4.99% (p=0.000 n=40+39)
GoTypes 780ms ± 3% 778ms ± 4% ~ (p=0.172 n=39+39)
Compiler 105ms ± 5% 99ms ± 7% -5.64% (p=0.000 n=40+40)
SSA 5.83s ± 6% 5.80s ± 6% ~ (p=0.556 n=40+40)
Flate 89.0ms ± 5% 87.0ms ± 6% -2.18% (p=0.000 n=40+40)
GoParser 172ms ± 4% 167ms ± 4% -2.72% (p=0.000 n=39+40)
Reflect 333ms ± 4% 333ms ± 3% ~ (p=0.426 n=40+39)
Tar 128ms ± 4% 126ms ± 4% -1.82% (p=0.000 n=39+39)
XML 173ms ± 4% 170ms ± 4% -1.39% (p=0.000 n=39+40)
[Geo mean] 253ms 248ms -2.13%
The profile is pretty transferable. Using the same profile, we
see a bigger win on Darwin/ARM64,
name old time/op new time/op delta
Template 71.0ms ± 2% 68.3ms ± 2% -3.90% (p=0.000 n=20+20)
Unicode 71.8ms ± 2% 66.8ms ± 2% -6.90% (p=0.000 n=20+20)
GoTypes 444ms ± 1% 428ms ± 1% -3.53% (p=0.000 n=19+20)
Compiler 48.9ms ± 3% 45.6ms ± 3% -6.81% (p=0.000 n=20+20)
SSA 3.25s ± 2% 3.09s ± 1% -5.03% (p=0.000 n=19+20)
Flate 44.0ms ± 2% 42.3ms ± 2% -3.72% (p=0.000 n=19+20)
GoParser 76.7ms ± 1% 73.5ms ± 1% -4.15% (p=0.000 n=18+19)
Reflect 172ms ± 1% 165ms ± 1% -4.13% (p=0.000 n=20+19)
Tar 63.1ms ± 1% 60.4ms ± 2% -4.24% (p=0.000 n=19+20)
XML 83.2ms ± 2% 79.2ms ± 2% -4.79% (p=0.000 n=20+20)
[Geo mean] 127ms 121ms -4.73%
For #60368.
Change-Id: I2cec0fc85e21c38d57ba6f0e5e90cde5d443ebd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/497455
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
We already refuse to build code in modules are too new (CL 476279).
This is a more comprehensive check: refuse to do anything at all with
modules or workspaces that are too new.
Since the module or workspace is new, it may have semantics we don't
understand and misinterpret well before we get to the actual building of code.
For example when we switched from // +build to //go:build that changed
the decision about which files go into a package, which affects the way
the overall load phase runs and which errors it reports. Waiting until the
building of code would miss earlier changes like that one.
Leaving the test from CL 476279 alone, but it's not load-bearing anymore.
For #57001.
Change-Id: I8c39943db1d7ddbcb9b5cae68d80459fddd68151
Reviewed-on: https://go-review.googlesource.com/c/go/+/497435
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
If a hash match is "disabled" (!enabled) indicate that in the
output with DISABLED. This is helpful in ensuring that multiple
package-directed command-line flags have the intended behavior,
e.g.
```
go build -a \
-gcflags=all=-d=gossahash=vn \
-gcflags=runtime=-d=gossahash=vy \
std
```
Output looks like
[DISABLED] [bisect-match 0x11d0ee166d9d61b4]
or (w/ "v"-prefixed hashcode )
sort/slice.go:23:29 note [DISABLED] [bisect-match 0xa5252e1c1b85f2ec]
gossahash triggered sort/slice.go:23:29 note [DISABLED] 100001011111001011101100
Change-Id: I797e02b3132f9781d97bacd0dcd2e80af0035cd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497216
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test is failing on the nocgo builder.
Change-Id: I9426ce77907956e4654fd437ad20e3af664e83ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/497436
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
To make the new go lines work with 'go get' as minimum requirements,
this CL creates a synthetic 'go' module that has as its versions the valid
versions that can be listed on the 'go' line.
In preparation for allowing 'toolchain' changes as well, an equivalent
synthetic module is introduced for 'toolchain'.
For #57001.
Change-Id: Id0ebbd283f0f991859d516d21dffe59a834db540
Reviewed-on: https://go-review.googlesource.com/c/go/+/497080
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
go install m@v and go run m@v are the only commands
that ignore the local go.mod. As such they need to use a
different signal to find the Go version, namely the m@v go.mod.
Because there is no way to predict that Go version (no equivalent
of "go version" for interrogating the local go.mod), if we do switch
toolchains we always print about it.
For #57001.
Change-Id: I981a0b8fa61992b353589355ba72a3b9d55914e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/497079
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Some custom toolchain builds add extra suffixes to the version.
Strip those off (cutting at - or +) to find the underlying Go version.
For #57001.
Change-Id: I234fb2d069aaf0922c0a2c848e4a4c38e4adf9bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/497415
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Clean up Go version comparison.
CL 494436 added an ad hoc version comparison for the toolchain switch.
There are also other version comparisons scattered throughout the code,
assuming that using semver.Compare with a "v" prefix gives the right answer.
As we start to allow versions like "go 1.21rc1" in the go.mod file,
those comparisons will not work properly.
A future CL will need to inject Go versions into semver for use with MVS,
so do what Bryan suggested in the review of CL 494436 and rewrite the
comparison in terms of that conversion.
For #57001.
Change-Id: Ia1d441f1bc259874c6c1b3b9349bdf9823a707d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/496735
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
When associating methods with their receiver base, we need to implement
the same indirection through Cgo types as is done for selector
expressions. This fixes a bug where methods declared on aliases of Cgo
types were not associated with their receiver.
While porting to types2, align the types2 testFiles helper with the
go/types implementation. In order to avoid call-site bloat, switch to an
options pattern for configuring the Config used to type-check.
Fixesgolang/go#59944
Change-Id: Id14101f01c122b6c856ae5453bd00ec07e83f414
Reviewed-on: https://go-review.googlesource.com/c/go/+/493877
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This patch revives the testing.Coverage() function, which takes a
snapshot of the coverage counters within an executing "go test -cover"
test binary and returns a percentage approximating the percent of
statements covered so far.
Fixes#59590.
Change-Id: I541d47a42d71c8fb2edc473d86c8951fa80f4ab0
Reviewed-on: https://go-review.googlesource.com/c/go/+/495450
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add a flag to EmitPercent indicating to emit a single line percent
summary across all packages as opposed to a line per package. We need
to set this flag when reporting as part of a "go test -cover" run, but
false when reporting as part of a "go tool covdata percent" run.
Change-Id: Iba6a81b9ae27e3a5aaf9d0e46c0023c0e7ceae16
Reviewed-on: https://go-review.googlesource.com/c/go/+/495448
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Relax the policy on counter mode clashes in certain cases for "go tool
covdata" operations. Specifically, when generating 'percent',
'pkglist' or 'func' reports, we only care about whether a given
statement is executed, thus counter mode clashes are irrelevant; there
is no need to report clashes for these ops.
Example:
$ go build -covermode=count -o myprog.count.exe myprog
$ go build -covermode=set -o myprog.set.exe myprog
$ GOCOVERDIR=dir1 ./myprog.count.exe
...
$ GOCOVERDIR=dir2 ./myprog.set.exe
...
$ go tool covdata percent i=dir1,dir2
error: counter mode clash while reading meta-data file dir2/covmeta.1a0cd0c8ccab07d3179f0ac3dd98159a: previous file had count, new file has set
$
With this patch the command above will "do the right thing" and work
properly, and in addition merges using the "-pcombine" flag will also
operate with relaxed rules. Note that textfmt operations still require
inputs with consistent coverage modes.
Change-Id: I01e97530d9780943c99b399d03d4cfff05aafd8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/495440
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Couple of test need to be skipped for GOEXPERIMENT=nocoverageredesign,
since they use "go build -cover". [This is a test-only CL].
Change-Id: I48c0855e2d8f042f9bc293e4cf48f326682112c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/495597
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Also clear the GOOS and GOARCH from the env file before testing other
environment variables.
This fixes various builders after CL 496957.
Change-Id: Ib0308ca48f9e64c1c872f1d26a92a1dedf6330f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/497256
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
If you are using a newer toolchain and set go env -w X=Y, then it's
a bit frustrating that you can't update the variable in an older toolchain
with go env -w X=OTHER or go env -u X, or even see it with go env X.
This CL makes all those work.
This is particularly important when playing with go env -w GOTOOLCHAIN=oldversion
because from that point on the old version is handling 'go env' commands,
and the old version doesn't know about GOTOOLCHAIN.
The most complete way to recover from that situation is to use
GOTOOLCHAIN=local go env -w ...
but we will backport this CL to Go 1.19 and Go 1.20 so that they can
recover a bit more easily.
Fixes#59870.
Change-Id: I7a0bb043109e75a0d746069015f6e7992f78287f
Reviewed-on: https://go-review.googlesource.com/c/go/+/496957
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
We don't normally keep explicit requirements for test dependencies of
packages loaded from other modules when the required version is
already the selected version in the module graph. However, in some
cases we may need to keep an explicit requirement in order to make use
of lazy module loading to disambiguate an otherwise-ambiguous import.
Note that there is no Go version guard for this change: in the cases
where the behavior of 'go mod tidy' has changed, previous versions of
Go would produce go.mod files that break successive calls to
'go mod tidy'. Given that, I suspect that any existing user in the
wild affected by this bug either already has a workaround in place
using redundant import statements (in which case the change does not
affect them) or is running 'go mod tidy -e' to force past the error
(in which case a change in behavior to a non-error should not be
surprising).
Fixes#60313.
Change-Id: Idf294f72cbe3904b871290d79e4493595a0c7bfc
Reviewed-on: https://go-review.googlesource.com/c/go/+/496635
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Many cgo integration tests do a lot of common setup in TestMain, and
that means they require a lot from the test environment to even get
off the ground. If something is missing, right now they print a "SKIP"
message to stderr and exit without running any tests.
Make these behave more like normal tests by instead setting a global
skip function if some precondition isn't satisfied, and having every
test call that. This way we run the tests and see them skip.
I would prefer something much more structured. For example, if we
replaced the global state set up by TestMain in these tests by instead
calling a function that returned that state (after setting it up on
the first call), that function could do the appropriate skips and
there would be no way to accidentally access this state without
checking the preconditions. But that's substantially more work and may
be much easier after we do further cleanup of these tests.
Change-Id: I92de569fd27596798c5e478402449cd735ec53a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/497096
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
There are many copies of overlaydir_test.go between the cgo tests
from when these couldn't share code. Now that they can, merge these
copies into a cmd/cgo/internal/cgotest package.
Change-Id: I203217f5d08e6306cb049a13718652cf7c447b80
Reviewed-on: https://go-review.googlesource.com/c/go/+/497078
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL is originally based on CL 484838 from rajbarik@uber.com.
Add a new PGO-based devirtualize pass. This pass conditionally
devirtualizes interface calls for the hottest callee. That is, it
performs a transformation like:
type Iface interface {
Foo()
}
type Concrete struct{}
func (Concrete) Foo() {}
func foo(i Iface) {
i.Foo()
}
to:
func foo(i Iface) {
if c, ok := i.(Concrete); ok {
c.Foo()
} else {
i.Foo()
}
}
The primary benefit of this transformation is enabling inlining of the
direct calls.
Today this change has no impact on the escape behavior, as the fallback
interface always forces an escape. But improving escape analysis to take
advantage of this is an area of potential work.
This CL is the bare minimum of a devirtualization implementation. There
are still numerous limitations:
* Callees not directly referenced in the current package can be missed
(even if they are in the transitive dependences).
* Callees not in the transitive dependencies of the current package are
missed.
* Only interface method calls are supported, not other indirect function
calls.
* Multiple calls to compatible interfaces on the same line cannot be
distinguished and will use the same callee target.
* Callees that only partially implement an interface (they are embedded
in another type that completes the interface) cannot be devirtualized.
* Others, mentioned in TODOs.
Fixes#59959
Change-Id: I8bedb516139695ee4069650b099d05957b7ce5ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/492436
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
A simple call to unsafe.StringData can't contain any pointers.
When looking for field references, a call to unsafe.StringData or
unsafe.SliceData can be treated as a type conversion.
In order to make unsafe.SliceData useful, recognize slice expressions
when calling C functions.
Fixes#59954
Change-Id: I08a3ace7882073284c1d46a5210582a2521b0b4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/493556
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Add the slog static analysis pass to `go vet`.
Vendor in golang.org/x/tools@master to pick up the pass.
Tweak a test in slog to avoid triggering the vet check.
Change-Id: I55ceac9a4e6876c8385897784542761ea0af2481
Reviewed-on: https://go-review.googlesource.com/c/go/+/496156
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We will soon have PGO specialization. It doesn't make sense for the
debug flag to have inline in the name, so rename it to pgodebug.
pgoinline is now a flag that can be used to disable PGO inlining.
Devirtualization will have a similar debug flag.
For #59959.
Change-Id: I9770ff1f0d132dfa3cd417018a887a1bd5555bba
Reviewed-on: https://go-review.googlesource.com/c/go/+/494716
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Provide an exported version of implements to easily check if a type
implements an interface. This will be use for PGO devirtualization.
Even within the package, other callers can make use of this simpler API
to reduce duplication.
For #59959.
Change-Id: If4eb86f197ca32abc7634561e36498a247b5070f
Reviewed-on: https://go-review.googlesource.com/c/go/+/495915
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
The documentation for Assignop specifies that if the assignment is not
valid, the reason for the failure is returned via a reason string
without failing the build.
A few cases in Assignop1 -> implements -> ifacelookdot directly call
base.Errorf rather than plumbing through the reason string as they
should. Drop these calls. Since error messages are mostly unreachable
here (it only applies to generated code), don't maintain them and allow
them to just fallthrough to the generic "missing method" message.
This is important for PGO specialization, which opportunistically checks
if candidate interface call targets implement the interface. Many of
these will fail, which should not break the build.
For #59959.
Change-Id: I1891ca0ebebc1c1f51a0d0285035bbe8753036bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/494959
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Before this CL, instructions such as SHA1SU0, AESD and AESE are encoded
in case 1 together with FMOV/ADD, and some error checking is missing,
for example:
SHA1SU0 V1.B16, V2.B16, V3.B16 // wrong data arrangement
SHA1SU0 V1.4S, V2.S4, V3.S4 // correct
Both will be accepted by the assembler, but the first one is totally
incorrect.
This CL fixes these potential encoding issues by moving them into
separate cases, adds some error tests, and also fixes a wrong encoding
operand for ASHA1C.
Change-Id: Ic778321a567735d48bc34a1247ee005c4ed9e11f
Reviewed-on: https://go-review.googlesource.com/c/go/+/493195
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#50335
Change-Id: I44b9dc6afa8c70b5cc8c79fb3ebddc3f45d3cef8
Reviewed-on: https://go-review.googlesource.com/c/go/+/475695
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
The documentation is yet to be written (more work in the go
command remains first). This CL implements the toolchain
selection described in
https://go.dev/design/57001-gotoolchain#the-and-lines-in-in-the-work-module
with these changes based on the issue discussion:
1. GOTOOLCHAIN=auto looks for a go1.19.1 binary in $PATH
and if found uses it instead of downloading Go 1.19.1 as a module.
2. GOTOOLCHAIN=path is like GOTOOLCHAIN=auto, with
downloading disabled.
3. GOTOOLCHAIN=auto+version and GOTOOLCHAIN=path+version
set a different minimum version of Go to use during the version
selection. The default is to use the newer of what's on the go line
or the current toolchain. If you are have Go 1.22 installed locally
and want to switch to a minimum of Go 1.25 with go.mod files
allowed to bump even further, you would set GOTOOLCHAIN=auto+go1.25.
The minimum is also important when there is no go.mod involved,
such as when you write a tiny x.go program and run "go run x.go".
That would get Go 1.25 in this example, instead of falling back to
the local Go 1.22.
Change-Id: I286625a24420424c313d1082b9949a463b2fe14a
Reviewed-on: https://go-review.googlesource.com/c/go/+/494436
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
The work to add the -json flag to the 'dist test' command also cleaned
how dist tests are tracked and registered. By now, a pair of (import
path, variant) strings is sufficient to uniquely identify every dist
test that exists. Some of the custom dist test names have been improved
along the way. And since the names are already changing a little anyway,
we use this opportunity to make them more uniform and predictable.
The mapping from the old dist test names to the new is as follows:
- "go_test:pkg" → "pkg" (this is the most common case)
- "go_test_bench:pkg" → "pkg:racebench"
- all other custom names are now called "pkg:variant", where variant
is a description of their test configuration and pkg is the import
path of the Go package under test
CL 495016 introduced test variants and used variant names for rewriting
the Package field in JSON events, and now that same name starts to also
be used as the dist test name.
Like previously done in CL 494496, registering a test variant involving
multiple Go packages creates a "pkg:variant" dist test name for each.
In the future we may combine their 'go test' invocation purely as an
optimization.
We can do this with the support of CL 496190 that keeps the coordinator
happy and capable of working with both new and old names.
In the end, all dist tests now have a consistent "pkg[:variant]" name.
For #37486.
For #59990.
Change-Id: I7eb02a42792a9831a2f3eeab583ff635d24269e8
Co-authored-by: Austin Clements <austin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/496181
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The moved_goroot test was the last user of the goroot functionality.
Now that it's been deleted, drop this and clean up loose ends.
Change-Id: Ie5e95644022dab76b1c06cf37f7729ee6616311f
Reviewed-on: https://go-review.googlesource.com/c/go/+/496520
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This test is largely obviated by the goroot_executable and
list_goroot_symlink cmd/go script tests. It's the last user of several
special-case features in cmd/dist and runs only under a fairly
constrained set of conditions (including only running on builders, not
locally). Delete it.
Change-Id: Icc744e3f9f04813bfd0cad2ef3e88e42617ecf5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/496519
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
This adds the loop type to the json/LSP logging, to help with
studies of how many loops of which kind were modified.
Change-Id: I637a630cd275b413259601c0070b963f3c6d2185
Reviewed-on: https://go-review.googlesource.com/c/go/+/496515
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, if a test prints an incomplete line and then exits, in JSON
mode, the filter we use to rewrite Package lines will keep the last
incomplete line in an internal buffer and never print it. In theory
this should never happen anyway because the test should only write
JSON to stdout, but we try pretty hard to pass through any non-JSON,
so it seems inconsistent to swallow incomplete lines.
Fix this by adding a testJSONFilter.Flush method and calling it in the
right places. Unfortunately this is a bit tricky because the filter is
constructed pretty far from where we run the exec.Cmd, so we return
the flush function through the various layers in order to route it to
the place where we call Cmd.Run.
Updates #37486.
Change-Id: I38af67e8ad23458598a32fd428779bb0ec21ac3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/496516
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Retrying the original CL with a small modification. The original CL
did not handle the case of reading an itab out of a dictionary
correctly. When we read an itab out of a dictionary, we must treat
the type inside that itab as maybe being put in an interface.
Original CL: 486895
Revert CL: 490156
Change-Id: Id2dc1699d184cd8c63dac83986a70b60b4e6cbd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/491495
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently STW events are only emitted for GC STWs. There's little reason
why the trace can't contain events for every STW: they're rare so don't
take up much space in the trace, yet being able to see when the world
was stopped is often critical to debugging certain latency issues,
especially when they stem from user-level APIs.
This change adds new "kinds" to the EvGCSTWStart event, renames the
GCSTW events to just "STW," and lets the parser deal with unknown STW
kinds for future backwards compatibility.
But, this change must break trace compatibility, so it bumps the trace
version to Go 1.21.
This change also includes a small cleanup in the trace command, which
previously checked for STW events when deciding whether user tasks
overlapped with a GC. Looking at the source, I don't see a way for STW
events to ever enter the stream that that code looks at, so that
condition has been deleted.
Change-Id: I9a5dc144092c53e92eb6950e9a5504a790ac00cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/494495
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Some C APIs require the use or structures that contain pointers to
buffers (iovec, io_uring, ...). The pointer passing rules would
require that these buffers are allocated in C memory and to process
this data with Go libraries it would need to be copied.
In order to provide a zero-copy way to use these C APIs, this CL
implements a Pinner API that allows to pin Go objects, which
guarantees that the garbage collector does not move these objects
while pinned. This allows to relax the pointer passing rules so that
pinned pointers can be stored in C allocated memory or can be
contained in Go memory that is passed to C functions.
The Pin() method accepts pointers to objects of any type and
unsafe.Pointer. Slices and arrays can be pinned by calling Pin()
with the pointer to the first element. Pinning of maps is not
supported.
If the GC collects unreachable Pinner holding pinned objects it
panics. If Pin() is called with the other non-pointer types it
panics as well.
Performance considerations: This change has no impact on execution
time on existing code, because checks are only done in code paths,
that would panic otherwise. The memory footprint on existing code is
one pointer per memory span.
Fixes: #46787
Signed-off-by: Sven Anderson <sven@anderson.de>
Change-Id: I110031fe789b92277ae45a9455624687bd1c54f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/367296
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
There is no harm in continuing type-checking a built-in even if there
is a version error.
Change-Id: I161abd904a26075694c26639e247a17126947fcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/496415
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Cuong Manh Le
Russ Cox
Matthew Dempsky
Cherry Mui
David Chase
Rob Findley
Than McIntosh
Bryan C. Mills
Austin Clements
Michael Pratt
Ian Lance Taylor
Jonathan Amsterdam
Robert Griesemer
Ruinan
Sean Liao
Dmitri Shuralyov
Paul E. Murphy
Keith Randall
Michael Anthony Knyszek
Sven Anderson
Oleksandr Redko