proposal: cmd/vet: add mechanism to silence false positives

[minux]

@josharian added an internal whitelist feature for vetting the standard
library. I think such a whitelisting feature is also useful for outside
packages.

(If cmd/vet could load project specific plugins, then this feature might
be less useful, but not all projects need custom vet checkers, so it
still makes sense to provide a simple whitelisting feature built in.)

Such a feature could be built upon @josharian's existing whitelist
feature (cmd/vet/all).

[adg]

cc @robpike

Seems reasonable to me.

[robpike]

Should be easy in principle but messy in detail. It's really up to Josh.

[josharian]

Fine by me, although I'm not going to volunteer to do it. :)

[rsc]

It would be nice to have a general mechanism to disable false positives from vet (or at least eliminate them all). I think we don't know what that should be, but we should solve that more general problem. Suggestions welcome.

With that problem solved, we could promote cmd/vet to be a more integral part of the compile-edit-debug cycle, for example doing things like run the test binary and vet on the directory at the same time, and make a vet failure count as a test failure by default.

[robpike]

I am adamant that source code not be annotated to silence vet. That will reduce the options available but that is my position.

[bradfitz]

//go:positionheard

// +solution !source_annotate

[minux]

I agree with Rob. No more magic comments (if vet set the precedence of magic comments to silence false positives, then soon other static checkers will follow suit and this will make Go code full of magic comments for different tools.)

[davecheney]

Seconded. Go code is already festooned with magic pragmas controlling the
interaction of variables and the garbage collector. Please let that be the
end of it.

On Tue, 8 Nov 2016, 14:30 Minux Ma notifications@github.com wrote:

I agree with Rob. No more magic comments (if vet set the precedence of
magic comments to silence false positives, then soon other static checkers
will follow suit and this will make Go code full of magic comments for
different tools.)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17058 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA4l4_SeqD0uM_ZdyUyVfINhuARz6ks5q7-zRgaJpZM4J54tu
.

[rsc]

We agree we don't want "vet:xxx" directives. We would like to fix the problem about false positives. But we don't have a solution. Any ideas?

It could be that we raise the bar for "on by default" in vet and fix up the noisy checks we want to keep. That would benefit everyone.

[rsc]

Maybe another option is to define a subset of the "go vet" on by default checks to be run during 'go test'. A few of the noisier ones might be on by default if you run "go vet" but not in the implicit vet during test.

[josharian]

The subset-of-vet-checks idea seems the most promising approach so far—no configuration plus no magic comments plus no unnecessary code changes pretty much requires zero false positives, and some of the existing, worthwhile vet checks don't meet that demanding bar.

It's worth considering separately whether we want a more general (configurable?) run-before-test hook, to inject other analysis tools, instead of something vet-specific.

[robpike]

Isn't that the purpose of an IDE or build wrapper? It seems wrong to build general layers of tooling into go test, which is already so complex it beggars belief.

As the person who suggested the subset approach, I can support calling out to go vet in go test, preferably under some flag (tests take long enough as it is), but cannot support a general test plugin mechanism.