cmd/go: go env GOMOD tries to download newer toolchain

[prattmic]

If go.mod says

module example.com

go 1.22

Then running go env GOMOD with 1.21 prints:

$ go env GOMOD
go: downloading go1.22 (linux/amd64)
go: download go1.22 for linux/amd64: toolchain not available

This is a bit silly, as go env needs to determine GOMOD in order to decide to upgrade in the first place.

cc @bcmills

[dmitshur]

I suspect in the general case this is working as intended. The Go 1.22 language isn't finalized yet, and in theory go env GOMOD in a Go 1.22 module may do something that today's go command doesn't know about and can only produce correct behavior by doing the download.

Does it work well to do go get go@go1.21 in said module before go env GOMOD if using Go 1.21 (RC 3 or so), or using a very recent gotip that knows how to work with a 1.22 module?

Edit: I see now that there's motivation to make a special exception for go env GOMOD. Never mind. :)

[bcmills]

Yep, go env GOMOD and go env GOWORK in particular have to be valid (or at least somewhat sensible), because those are what we use to determine which toolchain to upgrade to.

I suppose it's possible that we upgrade the toolchain via the go.mod and/or go.work file that we find and then the reinvoked toolchain decides to do something else instead (perhaps based on an environment variable), but a change that affects that sequence seems unlikely in the foreseeable future.