cmd/go: GOTOOLCHAIN=version+auto doesn't use the named version in go install

[cespare]

Go version

go1.21.13 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN='/home/caleb/bin'
GOCACHE='/home/caleb/.cache/go-build'
GOENV='/home/caleb/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/caleb/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/caleb/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/caleb/apps/oldgo/go1.21.13'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/caleb/apps/oldgo/go1.21.13/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.13'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
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 -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2590561090=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I believe this reproduces with more recent Go versions as well, but since the bug is about upgrading Go toolchain versions it's easier to demonstrate with an older version.

Here's what happens when I use the go command bundled with 1.21.13:

$ GOTOOLCHAIN=local go version
go version go1.21.13 linux/amd64
$ mkdir -p /tmp/x && GOBIN=/tmp/x GOTOOLCHAIN=go1.23.0+auto go install honnef.co/go/tools/cmd/staticcheck@2024.1.1 && go version /tmp/x/staticcheck
go: honnef.co/go/tools@v0.5.1 requires go >= 1.22.1; switching to go1.22.6
/tmp/x/staticcheck: go1.22.6

Here's what happens when I use the go command bundled with 1.23.0:

$ GOTOOLCHAIN=local go version
go version go1.23.0 linux/amd64
$ mkdir -p /tmp/x && GOBIN=/tmp/x GOTOOLCHAIN=go1.23.0+auto go install honnef.co/go/tools/cmd/staticcheck@2024.1.1 && go version /tmp/x/staticcheck
/tmp/x/staticcheck: go1.23.0

What did you see happen?

With GOTOOLCHAIN=go1.23.0+auto, Go 1.21.13 built the binary with Go 1.22.6.

What did you expect to see?

I would expect both invocations to build staticcheck using Go 1.23.0.

honnef.co/go/tools/cmd/staticcheck@2024.1.1 has go 1.22.1 in its go.mod. So it makes sense that I've I'm using Go 1.21.13, if I ran GOTOOLCHAIN=auto go install honnef.co/go/tools/cmd/staticcheck@2024.1.1, it would use Go 1.22.6 since that's the latest patch release of the previous Go version and that's the minimum version of the three options documented at https://go.dev/doc/toolchain#switch.

However, as documented at https://go.dev/doc/toolchain#intro, the <name>+auto form of the GOTOOLCHAIN var essentially tells the Go tool to use the maximum of <name> and whatever Go version auto would use:

The alternate form +auto sets the default toolchain to use before deciding whether to switch further. For example GOTOOLCHAIN=go1.21.3+auto directs the go command to begin its decision with a default of using Go 1.21.3 but still use a newer toolchain if directed by go and toolchain lines.

As far as I can tell, go install is entirely ignoring the <name> part of <name>+auto and just behaving the same as if I'd used GOTOOLCHAIN=auto.

[gabyhelp]

Related Issues and Documentation

• cmd/go: automatic toolchain upgrades make the combination of `go version` and `go install <package>@<version>` confusing #66518
• Go Toolchains > Introduction
• Go Toolchains > Go toolchain selection
• cmd/go: go toolchain version switch doesn't work when only language version is set in go.mod #65580 (closed)
• cmd/go: toolchain selection interacts unexpectedly with non-standard toolchains #63357 (closed)
• cmd/go: GOTOOLCHAIN=<name>+[auto|path] is incorrectly rejected as "invalid minimum toolchain" #61068 (closed)
• cmd/go: mod tidy reports toolchain not available with 'go 1.21' #62278 (closed)
• Go Toolchains > Go toolchain switches
• cmd/go: go1.22 toolchain not available #65631 (closed)
• Forward Compatibility and Toolchain Management in Go 1.21 > Toolchain Management

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

[prattmic]

cc @matloob @samthanawalla