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

$ go version
go version go1.12.7 darwin/amd64

Does this issue reproduce with the latest release?

I have tried it with the golang:1.13-rc docker image, and it does reproduce. Same with the golang:1.12.5-stretch docker image.

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

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/paulbrousseau/Library/Caches/go-build"
GOEXE=""
GOFLAGS="-mod=vendor"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/paulbrousseau/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.7/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.7/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="0"
GOMOD="/Users/paulbrousseau/work/devex/go/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/ys/3_9lwjwj3hj9nbry2j249x5h0000gq/T/go-build483197916=/tmp/go-build -gno-record-gcc-switches -fno-common"

In addition, I have GO111MODULE=on

What did you do?

I have a monorepo with many packages. Most are libraries, but a few are applications. My intention is to vet the code, test the code, and build the code via a shell script, and as quickly as possible. In this respect, I am running go vet ./... rather than checking each individual package.

I have cgo disabled so that for our Linux builds, we can create static binaries for easy dockerization. The builds are happy.

There is one application which directly imports the Neo4J go packages, and these require cgo. When I build that one application, I enable cgo, and it's also happy.

Circling back to go vet, if I run with cgo enabled, it's happy. If I run with cgo disabled, I get errors (see below). I understand why those errors occur; the structs are defined in files that import "C", and with cgo disabled, they are unavailable. Cool. But it is my understanding that as of some versions ago, go tools (lint, etc.) were supposed to ignore the vendor directory.

What did you expect to see?

No problems from go vet, as the troublesome package is in vendor.

What did you see instead?

# github.com/neo4j-drivers/gobolt
vendor/github.com/neo4j-drivers/gobolt/connector_worker.go:30:14: undefined: Config
vendor/github.com/neo4j-drivers/gobolt/connector_worker.go:31:15: undefined: seaboltConnector

Etc.

I have a hypothesis. go vet isn't the tool which is unhappy with the Neo4J libraries. But maybe go vet has to compile my code, so that it can do its analysis? And if cgo is disabled, it can't do so.

If that's the case, is there some way that I can work around this and still use ./... to go vet? If I build first and vet later, will vet discover the built packages (and if so, how does that work if I build to a non-standard location)?