cmd/go: import cycles in tests lead to too harsh and confusing errors

[dominikh]

For the following package, in txtar format

-- bar.go --
package bar

import (
	_ "context"
)
-- bar_test.go --
package bar

import _ "example.com/rec/bar"
-- go.mod --
module example.com/rec/bar

go 1.17

using go/packages with

cfg := &packages.Config{
	Tests: true,
	Mode:  packages.NeedExportsFile,
}
packages.Load(cfg, ".")

results in a single package named command-line-arguments and the following single error:

-: # example.com/rec/bar [example.com/rec/bar.test]
./bar.go:4:4: could not import context (open : no such file or directory)
./bar_test.go:3:10: could not import example.com/rec/bar (import "example.com/rec/bar" while compiling that package (import cycle))
# example.com/rec/bar [example.com/rec/bar.test]
./bar.go:4:4: could not import context (open : no such file or directory)
./bar_test.go:3:10: could not import example.com/rec/bar (import "example.com/rec/bar" while compiling that package (import cycle))

There are several issues with this:

• Why is there no working package for package bar? The tests don't build, but the package itself should build just fine.
• Why is the error message duplicated?
• Why are we failing to import context? That is, why is the path we're trying to open empty? (And why are we trying to open it in the first place?)

/cc @matloob

[dominikh]

The answer is that it's go list's fault. These errors come from go list on stderr:

$ go list -e -json -compiled=false -test=true -export=true -deps=false -find=false -- . >/dev/null
# example.com/rec/bar [example.com/rec/bar.test]
./bar.go:4:4: could not import context (open : no such file or directory)
./bar_test.go:3:10: could not import example.com/rec/bar (import "example.com/rec/bar" while compiling that package (import cycle))
# example.com/rec/bar [example.com/rec/bar.test]
./bar.go:4:4: could not import context (open : no such file or directory)
./bar_test.go:3:10: could not import example.com/rec/bar (import "example.com/rec/bar" while compiling that package (import cycle))

So this is another instance of go list -e writing to stderr. This case is particularly unfortunate, because go list also emits perfectly fine and populated JSON for all the packages (https://go.dev/play/p/YMAh-r5xoW6)

This probably warrants filing a separate issue for go list.