cmd/vet: throwing "refers to unknown identifier" error depending on file loading order

[bytheway]

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

go version go1.11.4 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/bbytheway/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/bbytheway/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/00/vxd1fq_x3_367zzc4k6rs0km03gnm5/T/go-build500153777=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I received an error from go vet when attempting to validate a custom errors package. It appears that there is a file loading order race condition with the custom package and the standard errors package.

I have created a repository with code that reproduces the issue.

https://github.com/bytheway/VetFailure

Essentially, go vet will return the error

./example_test.go:7: ExampleDemo refers to unknown identifier: Demo

when run bare, but if you feed the files to go vet in a reversed order, it passes.

This is probably related to having 2 files using the errors_test package, one of them also using the stdlib errors package (imported to a goErrors name). If the one importing stdlib errors comes first, go vet is unable to resolve the ExampleFunc() identifiers. If the order is reverse (examples, then the tests w/stdlib errors), then go vet passes.

What did you expect to see?

go vet should validate that the files are properly formed.

What did you see instead?

go vet detects a spurious error.

[ianlancetaylor]

I can reproduce the problem with Go 1.11, but it is fixed on tip.

[mvdan]

I too fail to reproduce this on tip (1.12). Vet has been heavily refactored in this cycle, so I'm assuming that the fix was part of that and would be very hard to backport.

/cc @alandonovan @ianthehat in case they have any ideas about a potential backport. But with 1.12 less than a month away, and given that this is an edge case in vet, I don't think it's worth the effort.

[alandonovan]

I don't think this warrants a backport. Closing.