cmd/go: Go toolchain ./... commands don't work with a combination of sub-modules and go.work file

[agnivade]

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

$ go version
go version devel go1.21-574c620901 Wed Mar 15 07:15:46 2023 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

This repro needs two repos for it to happen.

1. Clone https://github.com/agnivade/modbug and https://github.com/agnivade/pgm (just a random repo I had) as sibling directories
2. cd modbug
3. Do go list ./... and observe everything work fine.
4. cd public from there, and repeat go list ./...

Error thrown: pattern ./...: main module (github.com/agnivade/modbug/v7) does not contain package github.com/agnivade/modbug/v7/public/model

Same error with go test ./... as well

Observations

1. Rename go.work file to something else present under modbug. Things start to work fine.
2. Providing the package path works. For example go test github.com/agnivade/modbug/public/v7/... works fine from inside public directory.

Notes

1. Do NOT simply run go mod tidy under modbug. You need to remove the import.go file before that. The expected state of the codebase is to run go mod tidy after removing import.go file. But the import.go file should remain nevertheless. (Yes I know it's weird. It's complicated to explain :P)

[agnivade]

cc @bcmills

[bcmills]

Is this related to #59480?

[agnivade]

No I don't believe so. Here, you are entering that submodule and doing ./... inside that. And this is very specifically related to the presence of a go.work file. Without the go.work file, everything works fine.

[seankhliao]

So in public, you're in a module, it's a subdirectory under a workspace, but the module isn't listed in go.work.

~/tmp/testrepo0172/modbug/public/model 0:00:00
master » go build     
main module (github.com/agnivade/modbug/v7) does not contain package github.com/agnivade/modbug/v7/public/model

I believe workspace has higher priority than the module, which is why it reports the main module to be the one rooted in the workspace directory (module github.com/agnivade/modbug/v7) and not the one in the nearest parent (module github.com/agnivade/modbug/public/v7).
With that view, the local package can't be part of the main module, because there's still a go.mod carving out a module starting at public.

[seankhliao]

Sounds like go is inferring the package name for . using just the workspace, which excludes the nearest go.mod.
But giving it the full name works, because it matches via the replaced dependency from the module in the workspace root.

#49632 #51604 are probably related but simpler cases

[agnivade]

Yes, there is a difference between ./... and <package_path>/....

I need to check if adding use ./public in go.work fixes the issue.

[agnivade]

Aha! That fixed it. Sorry for the noise. No bug here. But rather a slightly misleading error perhaps.