cmd/go: using a module path without dot fails to build after toolchain selection [1.20 backport]

[dmitshur]

Similar to #61871, but:

$ cd $(mktemp -d)    
$ go mod init example/m
go: creating new go.mod: module example/m
$ go get go@1.20
go: downgraded go 1.21.0 => 1.20
$ echo "package main; func main() {}" > main.go

$ GOTOOLCHAIN=go1.20.7 go run .
ambiguous import: found package example/m in multiple modules:
	example/m (/tmp/LpbXADzD)
	 (/Users/gopher/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.20.7.darwin-arm64/src/example/m)
$ echo $?
1

It works fine without toolchain selection, or if a dot is used in first path element.

I noticed because I usually type something short (i.e., without a dot in first path element) when running a throwaway program locally. I know import paths without a dot are reserved for the standard library and shouldn't be used, but example/... and test/... are reserved for user progams per #37641.

CC @bcmills, @matloob, @rsc.

[bcmills]

@gopherbot, please backport to Go 1.21. This is a very confusing failure mode.

[gopherbot]

Backport issue(s) opened: #61896 (for 1.21).

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

[bcmills]

I think this is actually a bug in go1.20.7, with a workaround for Go 1.21 in https://go.dev/cl/504119 and a proper fix pending in https://go.dev/cl/504063.

[bcmills]

If so, that should imply that if you install go1.20.7 locally (so that it can be found via $PATH instead of in the module cache), then you will not observe this odd failure.

It should also not be present if you set GOTOOLCHAIN to, say, go1.21rc3.

[gopherbot]

Change https://go.dev/cl/518415 mentions this issue: cmd/go: do not index std as a module in modcache

[dmitshur]

should imply that if you install go1.20.7 locally (so that it can be found via $PATH instead of in the module cache), then you will not observe this odd failure.

It should also not be present if you set GOTOOLCHAIN to, say, go1.21rc3.

Both statements are true based on a quick local run.

I think it would be fine to close this issue as fixed in the Go1.22 or Go1.21 milestone, and make a new one for Go 1.20 backport. But since it's being repurposed to be a backport issue directly, I'll update the title and labels accordingly.