Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: toolchain selection interacts unexpectedly with non-standard toolchains #63357

Closed
dmitshur opened this issue Oct 3, 2023 · 1 comment
Assignees
Labels
GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@dmitshur
Copy link
Contributor

dmitshur commented Oct 3, 2023

Consider a non-standard toolchain with a Go version like "go1.21.1 X:loopvar" or "go1.21.1-issue63357", and a toolchain directive with the value "go1.21.1" exactly. When I first ran into this, it wasn't immediately clear to me if it would be better for that to cause the released Go toolchain "go1.21.1" to be downloaded and used, or for the non-standard toolchain to be deemed equal. Both options have some upsides. But whichever it is, it should be possible to figure out from the docs.

Consider that https://go.dev/doc/toolchain#version and https://go.dev/doc/toolchain#name include:

Any two Go versions can be compared to decide whether one is less than, greater than, or equal to the other.

Toolchains are compared by comparing the version V embedded in the name (dropping the initial go and discarding off any suffix beginning with -). For example, go1.21.0 and go1.21.0-custom compare equal for ordering purposes.

And https://go.dev/doc/toolchain#select includes:

If the go.work or go.mod file has a toolchain <tname> line and <tname> is newer than the default Go toolchain, then the go command runs <tname> instead.

So the documentation suggests the answer is they should be considered equal, at least for "go1.21.1-issue63357", and from briefly asking @rsc about this he expected that a non-standard toolchain built with a non-default GOEXPERIMENT isn't different enough to trigger toolchain downloads either.

What did you do?

Details about two types of non-standard toolchain

Using go1.21.1 as base:

$ cd $(mktemp -d)
$ git clone https://go.googlesource.com/go && cd go
$ git checkout go1.21.1

And becoming non-standard by either simplify giving its version a suffix:

# edit first line of VERSION file to say "go1.21.1-issue63357"
# (presumably there may be code changes along with the suffix, but they're not needed for repro)
$ cd src && ./make.bash
$ ../bin/go version
go version go1.21.1-issue63357 darwin/arm64

Or building the toolchain with some GOEXPERIMENT:

$ cd src
$ GOEXPERIMENT=loopvar ./make.bash
$ ../bin/go version
go version go1.21.1 X:loopvar darwin/arm64

In both cases you get a toolchain that's very similar to the standard go1.21.1, but both go version and runtime.Version() report strings that are not equal to the string "go1.21.1".


To reproduce this issue, I built a non-standard toolchain "go1.21.1-issue63357" (that said, the same behavior can be reproduced with a non-standard toolchain like "go1.21.1 X:loopvar"):

$ GOTOOLCHAIN=local go version
go version go1.21.1-issue63357 darwin/arm64

$ cd $(mktemp -d)
$ go mod init example.com/m
go: creating new go.mod: module example.com/m

$ go get go@1.21.0
go: downgraded go 1.21.1 => 1.21.0
go: added toolchain go1.21.1

Which results in the go.mod file:

module example.com/m

go 1.21.0

toolchain go1.21.1

Then I ran go version to see what toolchain would be selected.

What did you expect to see?

Expected the local non-standard toolchain to be used, Go version "go1.21.1-issue63357", and no toolchain download to be triggered:

$ go version
go version go1.21.1-issue63357 darwin/arm64

What did you see instead?

It triggered a toolchain download of "go1.21.1" and selected that one instead:

$ go version
go: downloading go1.21.1 (darwin/arm64)
go version go1.21.1 darwin/arm64

CC @rsc, @bcmills, @matloob.

@dmitshur dmitshur added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Oct 3, 2023
@dmitshur dmitshur added this to the Backlog milestone Oct 3, 2023
@bcmills bcmills self-assigned this Oct 13, 2023
@bcmills bcmills added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 13, 2023
@bcmills bcmills modified the milestones: Backlog, Go1.22 Oct 13, 2023
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 13, 2023
@gopherbot
Copy link

Change https://go.dev/cl/535355 mentions this issue: cmd/go: allow suffixed toolchains to satisfy toolchain lines for the same base version

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

3 participants