cmd/vet: document interaction with test sources

[cosmin-mogos]

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

$ go version
go version go1.12.5 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/cosmin/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/cosmin/go:/home/cosmin/dev/git"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go-1.12.5"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.12.5/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build217071151=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Run go vet something_test.go

What did you expect to see?

Successful execution

What did you see instead?

isomething_test.go: undefined: MyModel

even if MyModel is defined and go test executes successfully.

It may be a regression of #26797

[bcmills]

Run go vet something_test.go

Does this reproduce for all _test.go files, or just a specific one?

[bcmills]

The arguments to go vet are a list of packages. Per https://tip.golang.org/cmd/go/#hdr-Package_lists_and_patterns:

As a special case, if the package list is a list of .go files from a single directory, the command is applied to a single synthesized package made up of exactly those files, ignoring any build constraints in those files and ignoring any other files in the directory.

So go vet is correct to treat references to symbols from other files as unresolved.

[bcmills]

It seems like the underlying problem you're stumbling on here is that the vet documentation isn't particularly clear on when and how the contents of _test.go files are vetted. Perhaps we can at least improve the documentation.

[bcmills]

CC @ianthehat @matloob @jayconrod

[cosmin-mogos]

Thank you for the fast reply, I have completely missed this detail.

[maruel]

@bcmills I found this issue while trying to understand what the hell was happening for my project (panicparse).

In the end, the issue I was seeing had the following characteristics:

• A new global in main.go
• Use it in main_test.go
• Use +build options in other files, in my case one with race, one with !race.
• Use go vet ./...
• I was not able to reproduce locally.

The failure looked like this: https://travis-ci.org/maruel/panicparse/jobs/541748155 on go version go1.12.5 linux/amd64.

go vet ./...
# github.com/maruel/panicparse/cmd/panic [github.com/maruel/panicparse/cmd/panic.test]
cmd/panic/main_test.go:15:3: undefined: stdErr
cmd/panic/main_test.go:17:4: undefined: stdErr
cmd/panic/main_test.go:32:7: undefined: raceEnabled

After much fiddling, I realized that I was caching the project's directory in travis, and this was somehow causing the problem. Tweaking the cache entry fixed it for me.

I'm noting this in case others are experiencing similar issues.

[tx0c]

This isn't something we will fix on the release branch, so closing this issue.

why was #26797 closed, till today I can reproduce with go1.12.6, why go vet complain undefined ... something; but it's clearly all well defined, because go test can pass.