govulncheck is failing due to a type checking problem while loading.

What you are describing should be a type checking error for compiling the package test when compiling outside of go test. Say go build yourmod.com/dir/test should fail. You may want to take a look at https://pkg.go.dev/cmd/go#hdr-Test_packages .

'Go test' recompiles each package along with any files with names matching the file pattern "*test.go". These additional files can contain test functions, benchmark functions, fuzz tests and example functions. See 'go help testfunc' for more. Each listed package causes the execution of a separate test binary. Files whose names begin with "" (including "_test.go") or "." are ignored.

Test files that declare a package with the suffix "_test" will be compiled as a separate package, and then linked and run with the main test binary.

There are actually up to 4 ways a directory can define Go packages once you take into account testing and binaries. Your definitions appear to be split over 2 of these. If the test package is a testing utility package that only used from go test, you might be avoiding seeing this as as a problem.

go vet ./... not complaining is a bit surprising to me. I am guessing that the go command is sending a different list of .go files than I would expect. Speculating though. Can you give a minimal reproducer? File contents + directory structure would help here.

My general advice for you though (that does not improve govulncheck) is to make sure test makes sense as a package on its own.

Thanks for the quick reply! The test package is never compiled outside of go test, which is why this hadn't caused problems, but yes, I was surprised that the results were different between go vet and govulncheck.

Can you give a minimal reproducer? File contents + directory structure would help here.

Are you able to repro the error using the repo/directory in the initial report (https://github.com/derat/bugs/tree/main/golang/govulncheck-global-in-test-file)?

% govulncheck ./...                 
govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.

Scanning for dependencies with known vulnerabilities...
govulncheck: Packages contain errors:
.../bugs/golang/govulncheck-global-in-test-file/test/lib.go:4:36: undeclared name: bar

% go vet ./...
%

If I add an additional reference to a variable that isn't declared anywhere, then go vet also fails:

% go vet ./...  
# github.com/derat/bugs/golang/govulncheck-globals/test
vet: test/lib.go:4:29: undeclared name: baz

Are you able to repro the error using the repo/directory in the initial report (https://github.com/derat/bugs/tree/main/golang/govulncheck-global-in-test-file)?

I was. Apologies for the reading comprehension issues on my side.

For reference for others here are the relevant files.

--- test/foo_test.foo ---
package test

import "testing"

var bar = "bar"

func TestFoo(t *testing.T) { doSomething() }

--- test/lib.go ---
package test

// govulncheck fails on the next line with "undeclared name: bar"
func doSomething() string { return bar }

--- main.go ---
package main

func main() {}

On this go vet -x ./... only shows one action being taken on this snippet:

	"GoFiles": [
		"/Users/taking/tmp/i55016/bugs/golang/govulncheck-global-in-test-file/test/lib.go",
		"/Users/taking/tmp/i55016/bugs/golang/govulncheck-global-in-test-file/test/foo_test.go"
	],

If this is the only action it is not surprising that go vet is silent.

Right now govulncheck is run with packages.Config.Tests == *testFlag (false by default). This effectively treats this as only having test/lib.go. I confirmed we are only loading one x/tools/go/packages.Package for test with this config. This will not type check.

If we turn packages.Config.Tests on we will inspect the package as both [test/lib.go] and [test/lib.go, test/foo_test.go]. The first of these will crash.

The code in question is being written in a way that it does not typecheck under all usages by not considering all of the ways a test package can be loaded (See https://pkg.go.dev/cmd/go#hdr-Test_packages). The simplest solution for users is to write code that conforms to all of the ways a package can be loaded. (In this case, the test package should either always use "_test.go" or do not mix ".go" with "_test.go" for the same conceptual package.)

go vet is being appropriately generous on code that does not type check. govulncheck should print an error on [test/lib.go]. It not printing an error and silently suppressing diagnostics would not helpful.

I am somewhat tempted to just consider this as "Unfortunate" and close. The only candidate alternative I can see is to change go/packages so that it can load [test/lib.go, test/foo_test.go] to match go vet ./....

Thanks for the investigation! For whatever it's worth, I'm glad that govulncheck printed an error here since it got me to fix some weird code.

Change https://go.dev/cl/436835 mentions this issue: go/analysis: add note about package loading.

I am going to close as Unfortunate for now. We will keep an eye out for this impacting others. If this is impacting you too, please let us know.

I'll try to add some internal documentation about what is going on in the meantime.