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

[rittneje]

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.)

[gabyhelp]

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]

CC @griesemer

[griesemer]

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]

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]

@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]

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]

@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).