cmd/go: some errors not reported with go list

[cherrymui]

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

tip (go1.21-4d9beb2052)

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

darwin/amd64

What did you do?

Having a module with two packages a and b. b is a main package. a imports b (erroneously).

go.mod

module m

go 1.21

a/a.go

package a

import _ "m/b"

b/b.go

package main

func main() {}

Run go list ./a ./b.

What did you expect to see?

Report the error for importing a non-importable package, like

a/a.go:3:8: import "m/b" is a program, not an importable package
m/a
m/b

What did you see instead?

No error, with 0 exit code.

$ go list ./a ./b
m/a
m/b
$ echo $?
0

Interestingly, go list -test ./a ./b reports the error, although the error has nothing to do with test files (there is none). The documentation doesn't seem to mention that the -test flag can cause different behavior for error reporting.

There are also some other errors not being reported with go list, but reported with go list -test. https://cs.opensource.google/go/go/+/master:src/cmd/go/testdata/script/vendor_import.txt is one example. bad.go and invalid.go contains some errors, but the go list command succeeded.

It looks like the different behavior is related to that this code https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/list/list.go;l=736-788 runs when -test is specified.

Found while working on CL https://golang.org/cl/474236.

cc @bcmills

[gopherbot]

Change https://go.dev/cl/477838 mentions this issue: cmd/go: permit "go list" error in some tests

[cherrymui]

After CL https://golang.org/cl/474236, when listing multiple packages, the default -pgo=auto mode will cause this code https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/list/list.go;l=736-788 to run, which will cause it to report the error. go list -pgo=off ./a ./b will get back to the previous (Go 1.20) unexpected behavior.

[seankhliao]

I thought blank imports of main packages were allowed as a way to track dependencies, eg when using the tools.go pattern.

[bcmills]

@seankhliao, go mod tidy allows them, but in general we expect go list to follow go build in terms of what errors it reports, and go build certainly will not let you import a package main explicitly.

[thockin]

I hit this through another vector, but similar. It seems very strange to assert that I can't list, when I am allowed to set up this construct in the first place. This is a breaking change - is it really worth it?

[bcmills]

@thockin, given that we don't understand why this ever worked differently in the first place, we can't easily restore that buggy behavior.

go list supports the -e flag to allow listing packages that may have errors. If the -e flag does not allow go list to proceed past these errors, please file a separate issue. (go list -e has had many bugs, but we have been slowly fixing those and hopefully we can keep moving it toward a better long-term state.)

[MadhavJivrajani]

We hit this in kubernetes as well while trying to test with go1.21rc2: kubernetes/kubernetes#118996
The -e workaround seems to work (kubernetes/kubernetes#119027), but I'm not sure adopting that is prudent in the long run.

[alexbozhenko]

@bcmills:
Hi.
Other issue that I reported #62228 was closed as duplicated.
But there I provide the reproducer, and I think it is caused by this commit: a5c7928

Or maybe that actually a separate issue, not a duplicate of this one?

[bcmills]

@alexbozhenko, thanks for flagging that commit. That's an interesting clue, although it still doesn't really explain why the PGO changes seemed to trigger this behavior. 😅

But I think that will help us investigate.