cmd/vet: identify 100% reliable checks for testing

[rsc]

For #18084 we need to find some way to run just the "100% reliable" vet checks. It's okay if a "100% reliable" check flags a false positive as long as there is a clean way to rewrite the code to avoid the false positive.

go test would need some way to invoke that set, like a new flag.

[mvdan]

Out of curiosity - why not disable by default those that aren't reliable on vet directly? I assume this is what go tool vet does with -shadow:

  -shadow
        check for shadowed variables (experimental; must be set explicitly)

I think the reason why go vet isn't used regularly more often is because it's not conservative by default. A good example is the standard library itself with the whitelist.

[josharian]

Perhaps so. The standard library is not a good test case though; it is unusual in virtue of being the standard library, and that accounts for much of the whitelist.

[rsc]

I think the whitelists for the standard library could be reduced dramatically by making various checks more precise or off by default.

When I spoke to @robpike about this, he believed strongly that the "default on" set should be allowed to include reports that were only, say, 90% reliable. It's hard to evaluate in the abstract but that sounds plausible.

Probably the way forward is to work on reducing false positives and figuring out the "clean rewrites" (i.e. not a //vet:goaway comment) that apply. If we can get the current default set to all be "100% reliable", that's great. If not, we'll have a concrete check to talk about instead of hypotheticals.

[btracey]

A common vet complaint in my packages is "composite literal uses unkeyed fields". If #18084 is accepted, would this be (effectively) considered a bug? One could argue that a clean rewrite is available (add the fields), but there are some good reasons not to use fields, legibility being one of them.

[rsc]

Yes, code is expected to use composite literals with keyed fields whenever the literal is initializing a struct defined in another package. Otherwise the package cannot safely add a new field without breaking clients of that package. This puts some teeth behind the requirement listed in https://golang.org/doc/go1compat. Please file a separate issue if you think we should relax this, and explain under what circumstances that make sense that would handle your case. (For example I could imagine relaxing when the package being used is an internal package.)

[calmh]

Are types from other packages that are really slices always recognized nowadays? I recall lots of issues with that warning on things like

package foo

type Vector []int

package bar

import "foo"

var v = foo.Vector{1, 2, 3}

At the very least it seemed unreliable, in that it depended on having a compiled version of foo available when vetting bar in order to avoid the warning, or something similar?

[josharian]

@calmh related issues: #16086, #11394, #15408.