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.

[gopherbot]

Closed by merging 1a91bb9 to release-branch.go1.20.

[bcmills]

This is fixed as far as Go 1.20. @dmitshur, I think there is still one final release planned for Go 1.19 — do you think this is worth fixing on that branch, given that Go 1.19 would normally be past its support window?

[dmitshur]

@bcmills I tested out the original repro steps with Go 1.19 as the "target toolchain" instead of 1.20, and it's hard for me to tell if it's affected by the same bug as described in this issue or a different one. It doesn't work either, but the error is different:

$ cd $(mktemp -d)
$ go mod init example/m
go: creating new go.mod: module example/m
$ go get go@1.19
go: downgraded go 1.21.0 => 1.19
$ echo "package main; func main() {}" > main.go
$ GOTOOLCHAIN=go1.19.12 go run .
import "": import of unknown directory
$ echo $? 
1

There's some connection to #61871, but that issue is about error text in invalid programs, while this issue was about valid programs not working. (But it's possible their root cause is the same.)

It's hard for me to say without more information, so leaving the decision to you. In general I think it's better not to break cmd/go in Go 1.19.13 at this point, even if it means some UX inconvenience (i.e., needing to include a "." in the import path of short example or test programs when trying to use them via toolchain selection). On the other hand if you're very confident in the safety of the fix and the same CL will work despite the error being seemingly different, you do have that opportunity to include the fix.

[bcmills]

My inclination is that it's not worth the risk to mess with the final 1.19 release: as a workaround, folks can always install it in $PATH to prevent it from being loaded from the module cache.