cmd/go: using go get go@{version} in a module without a go directive can print a misleading "downgraded" message

[dmitshur]

What version of Go are you using (go version)?

$ go version
go version go1.21.3 darwin/arm64

What did you do?

https://go.dev/ref/mod#go-mod-file-go specifies:

If the go directive is missing, go 1.16 is assumed.

Consider:

$ cat go.mod
module example.com/m
$ cat p.go 
package p; import "cmp"; var _ = cmp.Less(1, 2)

The error message that go test prints is consistent with that (provided it's not due to #63489):

$ go test
# example.com/m
./p.go:1:34: implicit function instantiation requires go1.18 or later (-lang was set to go1.16; check go.mod)

But when doing something like go get go@1.20 (or go mod tidy), the module appears to behave as if it implicitly had the go command's version instead of 1.16.

What did you expect to see?

$ go get go@1.20
go: upgraded go 1.16 => 1.20
go: added toolchain go1.21.3

What did you see instead?

$ go get go@1.20
go: downgraded go 1.21.3 => 1.20
go: added toolchain go1.21.3

CC @rsc, @bcmills.

[bcmills]

The downgraded message is definitely misleading, and we should definitely fix that. 😅

The asymmetric behavior is intentional, though. When we first introduced the go directive we had the property that commands that add it always add the current version, not an old version. But we also have compatibility to contend with, meaning that a go command in a very old repo should use the semantics appropriate to that repo.

Those two goals are in tension, and the way we resolved that tension is: if we are going to write out a go version in a module that did not have one, we write the current version, but if we are not going to write it out we assume an old (and very widely compatible) version.