cmd/compile: Go 1.22 changes support for modules that declare go 1.0

[dmitshur]

Go version

go version go1.22rc2 darwin/arm64

Output of go env in your module/workspace:

(Shouldn't be relevant; happy to provide otherwise.)

What did you do?

I used a Go 1.22-ish toolchain, instead of a 1.21-ish one, to install the command go.chromium.org/luci/cipd/client/cmd/cipd@latest. It failed because one of its dependencies has a go module directive with an unusually-low value of "1.0" here, reporting a build error as:

# github.com/danjacques/gofslock/fslock
compile: invalid value "go1" for -lang: should be something like "go1.12"

Here's a smaller reproducer:

$ cd $(mktemp -d)
$ go mod init test
$ go get [email protected] toolchain@none
$ echo 'package p; import _ "github.com/danjacques/gofslock/fslock"' > p.go
$ go get . github.com/danjacques/[email protected]

What did you see happen?

$ go test
# github.com/danjacques/gofslock/fslock
compile: invalid value "go1" for -lang: should be something like "go1.12"
FAIL	test [build failed]

$ GOTOOLCHAIN=go1.21.6 go test
?   	test	[no test files]
$ echo $?
0

What did you expect to see?

I'm not sure if this edge-case should work or not.

I read over https://go.dev/doc/toolchain#version, which includes:

The syntax ‘1.N’ is called a “language version”. It denotes the overall family of Go releases implementing that version of the Go language and standard library.

But doesn't seem to specify what the minimum value of N is.

The new go/version package has IsValid, which reports true for "go1.0" and "go1". (https://go.dev/play/p/82xhtZbE9N9?v=gotip)

[bcmills]

Both gover.Lang and version.Lang have tests that a bare "1" is considered a valid language version:

• https://cs.opensource.google/go/go/+/refs/tags/go1.22rc2:src/internal/gover/gover_test.go;l=82;drc=b54cae276aa7997d91e1ce5de6e27ec60b19e4bb
• https://cs.opensource.google/go/go/+/master:src/go/version/version_test.go;l=53;drc=79738217d53f6b2d06d47a2233e51cc859d69e8d

On the other hand, cmd/compile expects to parse the -lang flag using a regular expression:

• https://cs.opensource.google/go/go/+/master:src/cmd/compile/internal/types/goversion.go;l=60-75;drc=c641d48afdf05de8aa15b4110cb07a2165c5f935

So I think two things need to happen here:

1. We should double check (with @rsc) that version.Lang("go1.0") really is intended to be go1 and not go1.0, and
2. assuming that it is, cmd/compile should be updated so that the -lang flag accepts all versions for which version.Lang(x) == x.

[rsc]

Lang("go1.0") = "go1" is correct; the compiler should accept "go1" in addition what it currently accepts namely "go1.0".

[gopherbot]

Change https://go.dev/cl/562322 mentions this issue: cmd/compile: accept -lang=go1 as -lang=go1.0

[bcmills]

@gopherbot, please backport to Go 1.22. This was a regression in 1.22.0 and the fix is trivial.

[gopherbot]

Backport issue(s) opened: #65619 (for 1.22).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[mdempsky]

Lang("go1.0") = "go1" is correct; the compiler should accept "go1" in addition what it currently accepts namely "go1.0".

On go.dev/cl/562322, I pointed out that cmd/go does not support "go 1" in go.mod files. @bcmills says this is expected because "go 1.0 is not the canonical name for that version."

I'll also point out that go mod edit -go=1 fails. (Both -toolchain=go1 and -toolchain=go1.0 are supported though.)

If cmd/go won't let its users spell Go language version "1.0" as "1", why did it start spelling "-lang=go1.0" as "-lang=go1"? Why is it cmd/compile's responsibility to now accept either spelling? Can cmd/go instead revert to the original spelling that it still requires from users?

Thanks.