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?