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

dmitshur · 2023-08-08T23:33:22Z

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.

The text was updated successfully, but these errors were encountered:

bcmills · 2023-08-09T15:44:54Z

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

gopherbot · 2023-08-09T15:45:08Z

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 · 2023-08-10T18:27:37Z

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 · 2023-08-10T18:29:16Z

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 · 2023-08-10T18:32:42Z

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

dmitshur · 2023-08-10T18:36:37Z

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.

We do not index std as a whole module ever. When working in the main Go repo, files in package change often, so we don't want to pay the cost of reindexing all of std when what we really need is just to reindex strings. Per-package indexing works better for that case. When using a released Go toolchain, we don't have to worry about the whole module changing, but if we switch to whole-module indexing at that point, we have the potential for bugs that only happen in released toolchains. Probably not worth the risk. For similar reasons, we don't index the current work module as a whole module (individual packages are changing), so we use the heuristic that we only do whole-module indexing in the module cache. The new toolchain modules live in the module cache, though, and our heuristic was causing whole-module indexing for them. As predicted, enabling whole-module indexing for std when it's completely untested does in fact lead to bugs (a very minor one). This CL turns off whole-module indexing for std even when it is in the module cache, to bring toolchain module behavior back in line with the other ways to run toolchains. Updates #57001. For #61873. Change-Id: I5012dc713f566846eb4b2848facc7f75bc956eb9 Reviewed-on: https://go-review.googlesource.com/c/go/+/504119 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> (cherry picked from commit a7b1793) Reviewed-on: https://go-review.googlesource.com/c/go/+/518415 Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>

gopherbot · 2023-08-14T22:06:06Z

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

bcmills · 2023-08-14T22:07:10Z

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 · 2023-08-14T23:09:42Z

@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 · 2023-08-15T00:32:44Z

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.

Due to a bug in Go 1.20 (see golang/go#61873), when importing a module without a dot in it, we get: ``` 18:13 ❱ GOTOOLCHAIN="go1.20+auto" go get akvorado: ambiguous import: found package akvorado in multiple modules: akvorado (/home/bernat/code/free/akvorado) (/home/bernat/src/gocode/pkg/mod/golang.org/toolchain@v0.0.1-go1.20.linux-amd64/src/akvorado) ``` This issue was fixed in Go 1.20.8 which was just released. By using `go1.20.8` as a toolchain for anything <= 1.20, we still cover the use case introduced in dependabot#7884, but we also avoid this bug. `go1.20.8` is a valid toolchain. For Go 1.20, only `go1.20` is a valid version for `go` directive in `go.mod`.

Due to a bug in Go 1.20 (see golang/go#61873), when importing a module without a dot in it, we get: ``` 18:13 ❱ GOTOOLCHAIN="go1.20+auto" go get akvorado: ambiguous import: found package akvorado in multiple modules: akvorado (/home/bernat/code/free/akvorado) (/home/bernat/src/gocode/pkg/mod/golang.org/toolchain@v0.0.1-go1.20.linux-amd64/src/akvorado) ``` This issue was fixed in Go 1.20.8 which was just released. By using `go1.20.8` as a toolchain for anything <= 1.20, we still cover the use case introduced in #7884, but we also avoid this bug. `go1.20.8` is a valid toolchain. For Go 1.20, only `go1.20` is a valid version for `go` directive in `go.mod`.

…t#7979) Due to a bug in Go 1.20 (see golang/go#61873), when importing a module without a dot in it, we get: ``` 18:13 ❱ GOTOOLCHAIN="go1.20+auto" go get akvorado: ambiguous import: found package akvorado in multiple modules: akvorado (/home/bernat/code/free/akvorado) (/home/bernat/src/gocode/pkg/mod/golang.org/toolchain@v0.0.1-go1.20.linux-amd64/src/akvorado) ``` This issue was fixed in Go 1.20.8 which was just released. By using `go1.20.8` as a toolchain for anything <= 1.20, we still cover the use case introduced in dependabot#7884, but we also avoid this bug. `go1.20.8` is a valid toolchain. For Go 1.20, only `go1.20` is a valid version for `go` directive in `go.mod`.

dmitshur added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Aug 8, 2023

dmitshur added this to the Backlog milestone Aug 8, 2023

bcmills self-assigned this Aug 9, 2023

bcmills modified the milestones: Backlog, Go1.22 Aug 9, 2023

gopherbot mentioned this issue Aug 9, 2023

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

Closed

bcmills modified the milestones: Go1.22, Go1.20.8 Aug 10, 2023

dmitshur added CherryPickCandidate Used during the release process for point releases and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Aug 10, 2023

dmitshur changed the title ~~cmd/go: using a module path without dot fails to build after toolchain selection~~ cmd/go: using a module path without dot fails to build after toolchain selection [1.21 backport] Aug 10, 2023

dmitshur changed the title ~~cmd/go: using a module path without dot fails to build after toolchain selection [1.21 backport]~~ cmd/go: using a module path without dot fails to build after toolchain selection [1.20 backport] Aug 10, 2023

heschi added the release-blocker label Aug 11, 2023

bcmills added the CherryPickApproved Used during the release process for point releases label Aug 11, 2023

gopherbot removed the CherryPickCandidate Used during the release process for point releases label Aug 11, 2023

gopherbot closed this as completed Aug 14, 2023

bcmills mentioned this issue Aug 25, 2023

cmd/go: ambiguous import with GOTOOLCHAIN set #62282

Closed

vincentbernat mentioned this issue Sep 6, 2023

go: fix ambiguous import when using a module without a dot dependabot/dependabot-core#7979

Merged

bcmills mentioned this issue Sep 18, 2023

cmd/go: error text for missing package import becomes confusing after toolchain selection #61871

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

dmitshur commented Aug 8, 2023

bcmills commented Aug 9, 2023

gopherbot commented Aug 9, 2023

bcmills commented Aug 10, 2023

bcmills commented Aug 10, 2023

gopherbot commented Aug 10, 2023

dmitshur commented Aug 10, 2023 •

edited

gopherbot commented Aug 14, 2023

bcmills commented Aug 14, 2023

dmitshur commented Aug 14, 2023 •

edited

bcmills commented Aug 15, 2023

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

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

Comments

dmitshur commented Aug 8, 2023

bcmills commented Aug 9, 2023

gopherbot commented Aug 9, 2023

bcmills commented Aug 10, 2023

bcmills commented Aug 10, 2023

gopherbot commented Aug 10, 2023

dmitshur commented Aug 10, 2023 • edited

gopherbot commented Aug 14, 2023

bcmills commented Aug 14, 2023

dmitshur commented Aug 14, 2023 • edited

bcmills commented Aug 15, 2023

dmitshur commented Aug 10, 2023 •

edited

dmitshur commented Aug 14, 2023 •

edited