cmd/vet: cannot run 'go vet' on testdata files

[dlsniper]

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

go version go1.10.2 windows/amd64

Does this issue reproduce with the latest release?

yes

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

set GOHOSTARCH=amd64
set GOHOSTOS=windows

What did you do?

I ran go vet on the file here: https://raw.githubusercontent.com/golang/go/27fb26c77c0374ec1876223593078e4d6b98d4f0/src/cmd/vet/testdata/cgo/cgo.go

What did you expect to see?

Vet errors as described by the comments // ERROR "embedded pointer"

What did you see instead?

C:\Go1.10\bin\go.exe vet D:\go\src\github.com\dlsniper\u\tmp\vet\vet.go
# command-line-arguments
C:\Users\florin\AppData\Local\Temp\go-build553891458\b001\_x002.o: In function `_cgo_3d8b191c8128_Cfunc_f':
/tmp/go-build/cgo-gcc-prolog:37: undefined reference to `f'
collect2.exe: error: ld returned 1 exit status

I've tried this on Linux as well as Windows. Same compile error and vet never has a chance to actually work. Do I miss anything here?
Thank you.

[dlsniper]

This also happen with the file from latest HEAD, see https://raw.githubusercontent.com/golang/go/2ce295e9542c104110a050bf809dd0a37e191eb7/src/cmd/vet/testdata/cgo/cgo.go

[mvdan]

I agree that this is inconsistent and a bit confusing. At the moment, cmd/vet sometimes requires types, and sometimes doesn't. If you look at its main.go, you'll see:

// Special case for "go vet" passing an explicit configuration:
// single argument ending in vet.cfg.
// Once we have a more general mechanism for obtaining this
// information from build tools like the go command,
// vet should be changed to use it. This vet.cfg hack is an
// experiment to learn about what form that information should take.
if flag.NArg() == 1 && strings.HasSuffix(flag.Arg(0), "vet.cfg") {
        doPackageCfg(flag.Arg(0))
        os.Exit(exitCode)
}

In particular, doPackageCfg sets mustTypecheck = true, which is otherwise false.

This is how go vet gets run - cmd/go runs first, it constructs a cfg file with the package loading information, and then calls cmd/vet with that. Then, if the file has typecheck errors, the tool bails. That is what you are seeing.

However, the tests run cmd/vet directly on lists of files or directories. That is the equivalent of running go tool vet instead of go vet. You can see the result:

$ go vet testdata/cgo/cgo.go
# command-line-arguments
cgo-gcc-prolog:37: error: undefined reference to 'f'
collect2: error: ld returned 1 exit status
$ go tool vet testdata/cgo/cgo.go
testdata/cgo/cgo.go:16: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:17: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:17: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:20: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:21: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:21: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:24: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:25: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:25: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:28: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:29: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:29: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:32: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:33: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:33: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:36: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:37: possibly passing Go type with embedded pointer to C
testdata/cgo/cgo.go:37: possibly passing Go type with embedded pointer to C
$ go version
go version devel +2ce295e954 Wed Jun 6 01:47:31 2018 +0000 linux/amd64

In the long run, once vet always requires type information, I would hope that its testdata will be reworked to contain files and directories where one can run go vet directly on. If any files were designed to make vet error in some way, I'd put those in a separate place like testdata/bad/.

/cc @alandonovan @josharian in case I missed anything or said anything wrong.

[mvdan]

If anyone wants to read the history on how we ended up with this complex situation: #21287 #16086

[ianlancetaylor]

@mvdan is correct, and this is not a bug. The cmd/vet tests test the vet tool in standalone mode. There is no reason to make them work in the mode in which vet is invoked by the go tool. If someone wants to change the vet tests to work with go vet, that's fine as long as existing functionality is preserved, but since this is not a bug I'm going to close this issue.