| Age | Commit message (Collapse) | Author |
|---|
|
The Go loop variable semantics changed in Go 1.22: loop variables are now
created per-iteration instead of per-loop. The compiler decides which
semantics to use based on the Go version in go.mod.
When go.mod specifies go 1.21 and the code is built with a Go 1.22+
compiler, the per-loop(compatible behavior) semantics should be used.
However, when a line directive is present in the source file,
go.mod 1.21 and go1.22+ compiler outputs a per-iteration semantics.
For example, the file below wants output 333 but got 012.
-- go.mod --
module test
go 1.21
-- main.go --
//line main.go:1
func main() {
var fns []func()
for i := 0; i < 3; i++ {
fns = append(fns, func() { fmt.Print(i) })
}
for _, fn := range fns {
fn()
}
}
The distinctVars function uses stmt.Pos().Base() to look up the file
version in FileVersions. Base() returns the file name after line
directives are applied (e.g., "main.go" for "//line main.go:1"), not
the actual source file path. This causes the version lookup to fail
for files with line directives.
This CL fixes the bug by using stmt.Pos().FileBase() instead. FileBase()
returns the actual file path before line directives are applied, ensuring
the correct version information is retrieved from the original source file.
Fixes: #77248
Change-Id: Idacc0816d112ee393089262468a02acfe40e4b72
Reviewed-on: https://go-review.googlesource.com/c/go/+/737820
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
|
|
Change-Id: I2ebadb87a4f60487c8f720930a72bc5ef953d7cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/696695
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
These will cause build failures once we vendor x/tools.
In once case I renamed a function err to errf to indicate
that it is printf-like.
Updates golang/go#68796
Change-Id: I04d57b34ee5362f530554b7e8b817f70a9088d12
Reviewed-on: https://go-review.googlesource.com/c/go/+/610739
Commit-Queue: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Tim King <taking@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
|
|
This commit is aimed at improving the readability and consistency
of the code base. Extraneous newline characters were present after
some return statements, creating unnecessary separation in the code.
Fixes #64610
Change-Id: Ic1b05bf11761c4dff22691c2f1c3755f66d341f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/548316
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
This includes version-dependent support for GOEXPERIMENT and
-d=loopvar, -d=loopvarhash, to allow testing/porting of old code.
Includes tests of downgrade (1.22 -> 1.21) and upgrade (1.21 -> 1.22)
based on //go:build lines (while running a 1.22 build/compiler).
Change-Id: Idd3be61a2b46acec33c7e7edac0924158cc726b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/508819
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
running on cmd/compile/internal/testdata/inlines now shows:
```
--- change set #1 (enabling changes causes failure)
b/b.go:16:6: loop variable i now per-iteration (loop inlined into b/b.go:10)
b/b.go:16:6: loop variable i now per-iteration
./b/b.go:16:6: loop variable b.i now per-iteration (loop inlined into a/a.go:18)
./b/b.go:16:6: loop variable b.i now per-iteration (loop inlined into ./main.go:37)
./b/b.go:16:6: loop variable b.i now per-iteration (loop inlined into ./main.go:38)
---
```
and
```
--- change set #2 (enabling changes causes failure)
./main.go:27:6: loop variable i now per-iteration
./main.go:27:6: loop variable i now per-iteration (loop inlined into ./main.go:35)
---
```
Still unsure about the utility of mentioning the inlined occurrence, but better
than mysteriously repeating the line over and over again.
Change-Id: I357f5d419ab4928fa316f4612eec3b75e7f8ac34
Reviewed-on: https://go-review.googlesource.com/c/go/+/494296
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: David Chase <drchase@google.com>
|
|
x/tools/cmd/bisect is changing to emit hex skips for robustness.
Update this copy of internal/bisect to understand them.
Change-Id: Ie9445714e8e9fb594e656db2f94dcde9b6ce82d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/494178
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Change-Id: I619c21ab9754f67b69215cfed238a3e489c7fbcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/493955
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
|
|
The FS form was only necessary for reliable hashes in tests,
and for that we can use -trimpath.
Another potential concern would be temporary work directory
names leaking into the names of files generated by cgo and the
like, but we already make sure to avoid those to ensure
reproducible builds: the compiler never sees those paths.
So the FS form is not necessary for that either.
Change-Id: Idae2c6acb22ab64dfb33bb053244d23fbe153830
Reviewed-on: https://go-review.googlesource.com/c/go/+/493737
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
Using more of internal/bisect gives us more that will be deleted
from base/hashdebug.go when we have updated the tools that
need the old protocol. It is also cheaper: there is no allocation to
make a decision about whether to enable, and no locking unless
printing is needed.
Change-Id: I43ec398461205a1a9e988512a134ed6b3a3b1587
Reviewed-on: https://go-review.googlesource.com/c/go/+/493736
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
Michael Stapelberg thought the former messages had
upside potential, Russ and I agreed.
Also slightly tweaked the json logging, not sure if
anyone will use it but it should at least be okay.
Change-Id: Iaab75114dd5f5d8f011fab22d32b57abc0272815
Reviewed-on: https://go-review.googlesource.com/c/go/+/493135
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Stapelberg <stapelberg@google.com>
|
|
CL 491875 introduces a new bisect command, which we plan to
document for use by end users to debug semantic changes in
the compiler and in GODEBUGs.
This CL adapts the existing GOSSAHASH support, which bisect
is a revision of, to support the specific syntax and output used
by bisect as well.
A followup CL will remove the old GOSSAHASH syntax and output
once existing consumers of that interface have been updated.
Change-Id: I99c4af54bb82c91c74bd8b8282ded968e6316f56
Reviewed-on: https://go-review.googlesource.com/c/go/+/491895
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
but this time, correctly.
children of Returns can have For/Range loops in them,
and those must be visited.
Includes test to verify that the optimization occurs,
and also that the problematic case that broke the original
optimization is now correctly handled.
Change-Id: If5a94fd51c862d4bfb318fec78456b7b202f3fcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/472355
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
This modifies the loopvar change to be tied to the
package if it is specified that way, and preserves
the change across inlining.
Down the road, this will be triggered (and flow correctly)
if the changed semantics are tied to Go version specified
in go.mod (or rather, for the compiler, by the specified
version for compilation).
Includes tests.
Change-Id: If54e8b6dd23273b86be5ba47838c90d38af9bd1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/463595
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
Adds:
GOEXPERIMENT=loopvar (expected way of invoking)
-d=loopvar={-1,0,1,2,11,12} (for per-package control and/or logging)
-d=loopvarhash=... (for hash debugging)
loopvar=11,12 are for testing, benchmarking, and debugging.
If enabled,for loops of the form `for x,y := range thing`, if x and/or
y are addressed or captured by a closure, are transformed by renaming
x/y to a temporary and prepending an assignment to the body of the
loop x := tmp_x. This changes the loop semantics by making each
iteration's instance of x be distinct from the others (currently they
are all aliased, and when this matters, it is almost always a bug).
3-range with captured iteration variables are also transformed,
though it is a more complex transformation.
"Optimized" to do a simpler transformation for
3-clause for where the increment is empty.
(Prior optimization of address-taking under Return disabled, because
it was incorrect; returns can have loops for children. Restored in
a later CL.)
Includes support for -d=loopvarhash=<binary string> intended for use
with hash search and GOCOMPILEDEBUG=loopvarhash=<binary string>
(use `gossahash -e loopvarhash command-that-fails`).
Minor feature upgrades to hash-triggered features; clients can specify
that file-position hashes use only the most-inline position, and/or that
they use only the basenames of source files (not the full directory path).
Most-inlined is the right choice for debugging loop-iteration change
once the semantics are linked to the package across inlining; basename-only
makes it tractable to write tests (which, otherwise, depend on the full
pathname of the source file and thus vary).
Updates #57969.
Change-Id: I180a51a3f8d4173f6210c861f10de23de8a1b1db
Reviewed-on: https://go-review.googlesource.com/c/go/+/411904
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
