cmd/vet: cache vet results

[jwebb]

go vet on a large codebase can take a nontrivial amount of time. It seems the Vet result for each package should be cacheable in much the same way as tests, i.e. the cache key is a combination of BuildID and Vet command line flags.

[seankhliao]

cc @matloob

[timothy-king]

You will also need to know if the vettool argument updated. This could be something like taking the hash of the binary at /path/to/tool when given -vettool=/path/to/tool.

[mvdan]

@timothy-king if we can assume that the vettool program is in Go, I imagine we could use something akin to go tool buildid to obtain the hash embedded in the binary. It doesn't make a big difference in terms of design, just an FYI.

[ianlancetaylor]

This is an optimization that is not visible to users, so taking this out of the proposal process.

[lukasschwab]

I think this would be really useful — cacheing seems like the single biggest impediment to using vet and analysis/multichecker in lieu of a fully-featured metalinter like golangci-lint, even for big complicated codebases.

golangci-lint's cache is built on a fork of the Go build cache — see

• the fork: golangci-lint/internal/go/cache
• the adapter: golangci-lint/internal/cache

You will also need to know if the vettool argument updated. This could be something like taking the hash of the binary at /path/to/tool when given -vettool=/path/to/tool.

I think a cacheing would be valuable even without tool-change invalidation, so long as one can provide go vet a flag that forces a cache miss (analogous to go test -count=1).

@ianlancetaylor I'd submit that this is visible to users insofar as the performance impact changes what you can feasibly use go vet to do (i.e. as a harness for custom linters in a complex project).