cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode #68658

rittneje · 2024-07-30T19:33:24Z

Go version

go version go1.23rc2 darwin/amd64

Output of `go env` in your module/workspace:

GO111MODULE='auto'
GOARCH='amd64'
GOBIN=''
GOCACHE='/tmp/.gocache'
GOENV='/Users/rittneje/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/rittneje/gomodtest/pkg/mod'
GONOPROXY='[REDACTED]'
GONOSUMDB='[REDACTED]'
GOOS='darwin'
GOPATH='/Users/rittneje/gomodtest'
GOPRIVATE='[REDACTED]'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/rittneje/sdk/go1.23rc2'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/rittneje/sdk/go1.23rc2/pkg/tool/darwin_amd64'
GOVCS='[REDACTED]'
GOVERSION='go1.23rc2'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/rittneje/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD=''
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/kf/kr7_s3xx0l12zbj3jrn082hmzy5gvy/T/go-build3078931624=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

As a minimal reproduction, we have a repository in GOPATH-mode, organized like so:

src
- foo
  - main.go

main.go is defined as follows:

//go:build go1.10

package p

import "fmt"

func main() {
	var x any
	fmt.Println(x)
}

What did you see happen?

Compiling with 1.23rc2 fails:

src/foo/main.go:8:8: predeclared any requires go1.18 or later (file declares //go:build go1.10)

What did you expect to see?

It should still work, like it does in 1.22.

(Please note the above is just a minimal reproduction. In reality, the offending go:build directive is in a vendored dependency.)

The text was updated successfully, but these errors were encountered:

gabyhelp · 2024-07-30T19:35:15Z

Related Issues and Documentation

cmd/go: Go modules initialised by go1.21.1 cannot be built using go1.20.8 #63279 (closed)
go get -v broken after upgrade go1.13.0 #34058 (closed)
Test #67906 (closed)
cmd/go: consider matching newly added _goos.go, _goarch.go or _goos_goarch.go suffixes based on go.mod go version (rather than Go toolchain version only) #44626
cmd/go: "leading dot in path element" for previously-undiagnosed paths in go 1.13 #34992 (closed)
cmd/go: go get go 1.13 cannot fetch vX.Y.Z if tag X.Y.Z is defined #32867 (closed)
cmd/go: go run cannot build a command in a module directory #33890 (closed)
cmd/go: emit an explicit error when packages in GOPATH/src/vendor overlap with GOROOT/src/vendor #34068
cmd/compile: could not import "package" (cannot import "package" (type parameter bound more than once), possibly version skew - reinstall package) #51836 (closed)
cmd/compile: internal compiler error with zero-size types #65808 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

ianlancetaylor · 2024-07-30T22:45:59Z

CC @griesemer

griesemer · 2024-07-30T23:33:48Z

I don't see what's wrong here: the file specifies the language version as go1.10 and any is not available in 1.10, so this error is legit. The code behaves the same for Go 1.21, Go 1.22 (not as claimed), and Go at tip (Go 1.23...).

If the issue exists in a larger code base, please provide a reproducer that accurately reflects the situation. Otherwise, please close this issue, thanks.

rittneje · 2024-07-31T03:31:25Z

The code behaves the same for Go 1.21, Go 1.22 (not as claimed), and Go at tip (Go 1.23...).

@griesemer False.

$ go version
go version go1.21.12 linux/amd64
$ go build ./src/...
$ echo $?
0

$ go version
go version go1.22.5 darwin/amd64
$ go build ./src/...
$ echo $?
0

$ ~/go/bin/go1.23rc2 version
go version go1.23rc2 darwin/amd64
$ ~/go/bin/go1.23rc2 build ./src/...
# _/Users/rittneje/gomodtest/src/foo
src/foo/main.go:8:8: predeclared any requires go1.18 or later (file declares //go:build go1.10)
$ echo $?
1

I'm going to guess that the playground compiles in "module mode" not "GOPATH mode" and thus is not a valid way to reproduce the issue I described.

griesemer · 2024-07-31T03:51:13Z

@rittneje I see. If the compiler is invoked without a valid -lang version, or a -lang version before go1.21, than file local versions are ignored and the code is compiled assuming the latest language version, despite the //go:build go1.10 line. Presumably that is what's happening in Go 1.22 and before.

I suspect a change in the way the go command invokes the compiler in GOPATH mode.
@golang/tools-team for visibility.

matloob · 2024-07-31T15:36:57Z

Yes, we changed how the go command invokes the compiler: https://go.dev/cl/593156 changes the go command to always pass in a language version (which in gopath mode it sets to the toolchain version, so as new a version as possible).

I think that the behavior of passing in the language version is the correct behavior. I also think that doing the downgrade is the correct behavior. But we can change the way the go command is invoked if it's decided that we don't want to do the downgrade in GOPATH mode (after all in the documentation of the buildconstraint downgrade it's mainly mentioned in the context of modules).

rittneje · 2024-07-31T16:07:04Z

@matloob I think it would be more helpful if there were a way for us to specify the language version to the compiler in GOPATH mode.

For example, right now any GOPATH-mode application compiled under 1.22+ will use the new loop semantics, without any ability to opt out (since they cannot use module directive).

griesemer · 2024-07-31T16:15:58Z

Perhaps GCFLAGS can be used to set -lang in GOPATH mode.

matloob · 2024-07-31T17:49:03Z

@matloob I think it would be more helpful if there were a way for us to specify the language version to the compiler in GOPATH mode.

For example, right now any GOPATH-mode application compiled under 1.22+ will use the new loop semantics, without any ability to opt out (since they cannot use module directive).

@rittneje This is the sort of thing the //go:build downgrade behavior that you're seeing on your example is for. Just like adding //go:build go1.10 sets the go version to Go 1.10 (disabling the use of any), you could set //go:build go1.21 to revert to the old for loop semantics on a go file that relies on the old behavior. The rule is that if there's a //go:build go version constraint we us the oldest version implied by that constraint for that file.

rittneje · 2024-07-31T18:17:20Z

@matloob Yes, but that would mean that a GOPATH-mode repo has to add //go:build go1.21 to every single file when upgrading to 1.22, which isn't exactly developer-friendly to say the least. (Nor do I think it is particularly aligned with the spirit of Go's goals of backwards compatibility.)

matloob · 2024-07-31T18:34:14Z

cc @samthanawalla

@rittneje I'm sorry, you're right. Looking at #60915, we decided to keep passing in language version go1.21 for GOPATH mode to avoid breaking compatibility. We'll fix this.

rittneje · 2024-07-31T18:56:11Z

@matloob It seems that with Go 1.22, a GOPATH-mode application will use the 1.22 loop semantics, even though it wasn't supposed to as per #60915. However, now that ship has sailed, and GOPATH-mode applications may well be relying on the 1.22 loop semantics, meaning that restoring 1.21 semantics as originally proposed is itself a breaking change.

gopherbot · 2024-07-31T20:55:26Z

Change https://go.dev/cl/602216 mentions this issue: cmd/go: pin the language version passed to the compiler for GOPATH mode

matloob · 2024-07-31T21:01:23Z

@rittneje That's a good point. My instinct is that we should still use "go1.21" as the language version passed to the compiler but I think there's no clear answer unfortunately.

I'll think about and discuss this with my colleagues to try to find the least negatively impactful solution.

gopherbot · 2024-08-22T21:08:13Z

Change https://go.dev/cl/607955 mentions this issue: go/types, types2: use max(fileVersion, go1.21) if fileVersion present

gopherbot · 2024-08-27T20:45:09Z

Change https://go.dev/cl/608797 mentions this issue: internal/versions: disable a test case incompatible with CL 607955

CL 607955 is changing the behavior of "//go:build" file versions. Before, file versions did not apply if go version was set for the package, but after CL 6079055, the package's go version does not influence whether the file version is applied: max(fileVersion, go1.21) will always be applied. Once CL 607955 is released in a go 1.23 minor release, we can update the test to require go1.23 and test for the new behavior (though it would fail for users building with a version of go older than the minor release with the behavior update). For golang/go#68658 Change-Id: I99d39ce108274edf401d861e553ad923b508f936 Reviewed-on: https://go-review.googlesource.com/c/tools/+/608797 Reviewed-by: Robert Griesemer <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>

matloob · 2024-08-27T21:32:27Z

@gopherbot please backport this to 1.23. It's necessary to unbreak GOPATH mode with certain build tags

gopherbot · 2024-08-27T21:33:19Z

Backport issue(s) opened: #69094 (for 1.23).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

Change the rules for how //go:build "file versions" are applied: instead of considering whether a file version is an upgrade or downgrade from the -lang version, always use max(fileVersion, go1.21). This prevents file versions from downgrading the version below go1.21. Before Go 1.21 the //go:build version did not have the meaning of setting the file's langage version. This fixes an issue that was appearing in GOPATH builds: Go 1.23.0 started providing -lang versions to the compiler in GOPATH mode (among other places) which it wasn't doing before, and it set -lang to the toolchain version (1.23). Because the -lang version was greater than go1.21, language version used to compile the file would be set to the //go:build file version. //go:build file versions below 1.21 could cause files that could previously build to stop building. For example, take a Go file with a //go:build line specifying go1.10. If that file used a 1.18 feature, that use would compile fine with a Go 1.22 toolchain. But it would produce an error when compiling with the 1.23.0 toolchain because it set the language version to 1.10 and disallowed the 1.18 feature. This breaks backwards compatibility: when the build tag was added, it did not have the meaning of restricting the language version. For #68658 Change-Id: I6cedda81a55bcccffaa3501eef9e2be6541b6ece Reviewed-on: https://go-review.googlesource.com/c/go/+/607955 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Robert Griesemer <[email protected]>

gopherbot · 2024-08-27T22:39:52Z

Change https://go.dev/cl/608935 mentions this issue: [release-branch.go1.23] go/types, types2: use max(fileVersion, go1.21) if fileVersion present

…) if fileVersion present Change the rules for how //go:build "file versions" are applied: instead of considering whether a file version is an upgrade or downgrade from the -lang version, always use max(fileVersion, go1.21). This prevents file versions from downgrading the version below go1.21. Before Go 1.21 the //go:build version did not have the meaning of setting the file's langage version. This fixes an issue that was appearing in GOPATH builds: Go 1.23.0 started providing -lang versions to the compiler in GOPATH mode (among other places) which it wasn't doing before, and it set -lang to the toolchain version (1.23). Because the -lang version was greater than go1.21, language version used to compile the file would be set to the //go:build file version. //go:build file versions below 1.21 could cause files that could previously build to stop building. For example, take a Go file with a //go:build line specifying go1.10. If that file used a 1.18 feature, that use would compile fine with a Go 1.22 toolchain. But it would produce an error when compiling with the 1.23.0 toolchain because it set the language version to 1.10 and disallowed the 1.18 feature. This breaks backwards compatibility: when the build tag was added, it did not have the meaning of restricting the language version. For #68658 Fixes #69094 Change-Id: I6cedda81a55bcccffaa3501eef9e2be6541b6ece Reviewed-on: https://go-review.googlesource.com/c/go/+/607955 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Robert Griesemer <[email protected]> (cherry picked from commit aeac0b6) Reviewed-on: https://go-review.googlesource.com/c/go/+/608935

gopherbot · 2024-08-28T23:16:01Z

Change https://go.dev/cl/609415 mentions this issue: [gopls-release-branch.0.16] internal/versions: disable a test case incompatible with CL 607955

gopherbot · 2024-08-28T23:27:06Z

Change https://go.dev/cl/609416 mentions this issue: [gopls-release-branch.0.16] all: disable tests incompatible with CL 603895

…03895 The tests disabled in this CL depend on being able to downgrade Go versions to versions earlier than Go 1.21. This behavior will change with CL 603895. Disable these tests for now and re-enable them with fixes in a later CL. For golang/go#68658 Change-Id: I13bdc03117989a128d90195ac90b2905102d293f Reviewed-on: https://go-review.googlesource.com/c/tools/+/604817 Commit-Queue: Michael Matloob <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Tim King <[email protected]> Auto-Submit: Michael Matloob <[email protected]> (cherry picked from commit 7f262d6) Reviewed-on: https://go-review.googlesource.com/c/tools/+/609416 Reviewed-by: Hyang-Ah Hana Kim <[email protected]> TryBot-Bypass: Robert Findley <[email protected]>

…compatible with CL 607955 CL 607955 is changing the behavior of "//go:build" file versions. Before, file versions did not apply if go version was set for the package, but after CL 6079055, the package's go version does not influence whether the file version is applied: max(fileVersion, go1.21) will always be applied. Once CL 607955 is released in a go 1.23 minor release, we can update the test to require go1.23 and test for the new behavior (though it would fail for users building with a version of go older than the minor release with the behavior update). For golang/go#68658 Change-Id: I99d39ce108274edf401d861e553ad923b508f936 Reviewed-on: https://go-review.googlesource.com/c/tools/+/608797 Reviewed-by: Robert Griesemer <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> (cherry picked from commit adb7301) Reviewed-on: https://go-review.googlesource.com/c/tools/+/609415 TryBot-Bypass: Robert Findley <[email protected]> Reviewed-by: Hyang-Ah Hana Kim <[email protected]>

gopherbot · 2024-08-29T18:19:03Z

Change https://go.dev/cl/609436 mentions this issue: cmd/go/testdata/script: add a test case for issue #68658

gopherbot · 2024-09-26T22:51:53Z

Change https://go.dev/cl/615698 mentions this issue: go/ssa/interp: reenable lifetime tests.

For golang/go#68658 Change-Id: I6e05e21f924cda18e368543e59071b2c79c16ef2 Reviewed-on: https://go-review.googlesource.com/c/tools/+/615698 Commit-Queue: Tim King <[email protected]> Reviewed-by: Alan Donovan <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>

gopherbot · 2024-09-27T20:10:47Z

Change https://go.dev/cl/615685 mentions this issue: go/analysis/passes/stdversion: reenable tests

timothy-king · 2024-09-27T21:20:15Z

@gopherbot please backport this to 1.22. It's necessary to have consistent file versions with build tags with later versions.

dmitshur · 2024-10-02T16:36:19Z

@timothy-king You're running into friction issue #25574 – there was already a backport request in #68658 (comment). As a workaround, you can create the 1.22 backport issue manually.

gopherbot · 2024-10-02T17:36:44Z

Change https://go.dev/cl/617495 mentions this issue: [release-branch.go1.22] go/types, types2: use max(fileVersion, go1.21) if fileVersion present

Enable units tests after 1.23. Tests were rewritten for the changes to the 1.21 file version event horizon. The test is not enabled for 1.22. A backport for golang/go#68658 may be required. For golang/go#68658 Change-Id: I15f46e3ff3de7c02592d5a357ae199116323c29f Reviewed-on: https://go-review.googlesource.com/c/tools/+/615685 Reviewed-by: Alan Donovan <[email protected]> Commit-Queue: Tim King <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>

timothy-king · 2024-10-02T21:28:55Z

The decision for the backport for 1.22 can be done on #69749. Closing this issue which is about 1.23 and 1.24.

seankhliao added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Jul 30, 2024

griesemer self-assigned this Jul 30, 2024

griesemer added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jul 30, 2024

griesemer added this to the Go1.23 milestone Jul 30, 2024

griesemer added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Jul 31, 2024

griesemer assigned matloob Jul 31, 2024

gopherbot removed the NeedsFix The path to resolution is known, but the work has not been done. label Jul 31, 2024

matloob added NeedsFix The path to resolution is known, but the work has not been done. release-blocker and removed NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Jul 31, 2024

gopherbot mentioned this issue Aug 27, 2024

cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode [1.23 backport] #69094

Closed

gopherbot closed this as completed in ffb3e57 Aug 29, 2024

gabyhelp mentioned this issue Sep 17, 2024

cmd/go: fullpath always enabled in GOPATH mode #69500

Closed

timothy-king reopened this Sep 27, 2024

timothy-king mentioned this issue Oct 2, 2024

go/types, cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode [1.22 backport] #69749

Closed

mknyszek removed the release-blocker label Oct 2, 2024

timothy-king closed this as completed Oct 2, 2024

gabyhelp mentioned this issue Oct 29, 2024

cmd/go: inconsistent reporting of default Go version #70090

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode #68658

cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode #68658

rittneje commented Jul 30, 2024

gabyhelp commented Jul 30, 2024

ianlancetaylor commented Jul 30, 2024

griesemer commented Jul 30, 2024

rittneje commented Jul 31, 2024 •

edited

Loading

griesemer commented Jul 31, 2024

matloob commented Jul 31, 2024

rittneje commented Jul 31, 2024

griesemer commented Jul 31, 2024

matloob commented Jul 31, 2024

rittneje commented Jul 31, 2024

matloob commented Jul 31, 2024

rittneje commented Jul 31, 2024

gopherbot commented Jul 31, 2024

matloob commented Jul 31, 2024

gopherbot commented Aug 22, 2024

gopherbot commented Aug 27, 2024

matloob commented Aug 27, 2024

gopherbot commented Aug 27, 2024

gopherbot commented Aug 27, 2024

gopherbot commented Aug 28, 2024

gopherbot commented Aug 28, 2024

gopherbot commented Aug 29, 2024

gopherbot commented Sep 26, 2024

gopherbot commented Sep 27, 2024

timothy-king commented Sep 27, 2024

dmitshur commented Oct 2, 2024

gopherbot commented Oct 2, 2024

timothy-king commented Oct 2, 2024

cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode #68658

cmd/go: breaking change in 1.23rc2 with version constraints in GOPATH mode #68658

Comments

rittneje commented Jul 30, 2024

Go version

Output of go env in your module/workspace:

What did you do?

What did you see happen?

What did you expect to see?

gabyhelp commented Jul 30, 2024

ianlancetaylor commented Jul 30, 2024

griesemer commented Jul 30, 2024

rittneje commented Jul 31, 2024 • edited Loading

griesemer commented Jul 31, 2024

matloob commented Jul 31, 2024

rittneje commented Jul 31, 2024

griesemer commented Jul 31, 2024

matloob commented Jul 31, 2024

rittneje commented Jul 31, 2024

matloob commented Jul 31, 2024

rittneje commented Jul 31, 2024

gopherbot commented Jul 31, 2024

matloob commented Jul 31, 2024

gopherbot commented Aug 22, 2024

gopherbot commented Aug 27, 2024

matloob commented Aug 27, 2024

gopherbot commented Aug 27, 2024

gopherbot commented Aug 27, 2024

gopherbot commented Aug 28, 2024

gopherbot commented Aug 28, 2024

gopherbot commented Aug 29, 2024

gopherbot commented Sep 26, 2024

gopherbot commented Sep 27, 2024

timothy-king commented Sep 27, 2024

dmitshur commented Oct 2, 2024

gopherbot commented Oct 2, 2024

timothy-king commented Oct 2, 2024

Output of `go env` in your module/workspace:

rittneje commented Jul 31, 2024 •

edited

Loading