proposal: cmd/vet: expose list of analyzers

[djmitche]

Proposal Details

When developing a custom analyzer for a project, it feels most natural to add that analyzer to the existing default analyzers, rather than run the two sets of analyzers in separate invocations.
However, cmd/vet/main.go currently contains the list of default analyzers for go vet, but does not provide a programmatic way to access this information.

In this proposal, the list of analyzers would be available in some global variable (or function) in cmd/vet or x/tools/analysis/all or some other suitable location. Something like

var Analyzers = []analysis.Analyzer {
		appends.Analyzer,
		asmdecl.Analyzer,
		assign.Analyzer,
		atomic.Analyzer,
		...
}

then a custom analyzer could use something like

var analyzers = []analysis.Analyzer {
  MyAnalyzer,
  MyOtherAnalyzer,
}
analyzers = append(analyzers, all.Analyzers...)
multichecker.Main(analyzers...)

[adonovan]

This seems reasonable. It should be a separate package, since it aggregates a large number of dependencies. I propose this API:

package vet // import "golang.org/x/tools/go/analysis/vet"

var Suite []*analysis.Analyzer

[gabyhelp]

Related Issues

• proposal: x/tools/go/analysis/vet: export cmd/vet's []*Analyzer suite #35487

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[mateusz834]

What about duplicates? Say at some point we add some new analyzer to this package, but someone else appends that same analyzer in some other code? Will it execute twice? Not sure whether that is a problem we should be worried about.

[adonovan]

What about duplicates? Say at some point we add some new analyzer to this package, but someone else appends that same analyzer in some other code? Will it execute twice? Not sure whether that is a problem we should be worried about.

Good question. The analysisflags.Validate function rejects duplicates with an error. We could relax that. Or we could make it the documented responsibility of the person augmenting the suite to check for presence before appending.

[djmitche]

This seems like a place where some responsibility on the part of the user is reasonable.

[prattmic]

The set of analyzers in vet depends on the toolchain version (since that contains vet), but the set of analyzers in vet.Suite would depend on the version of x/tools.

Would that ever matter? It doesn’t sound like a big deal for the uses here, but it is perhaps confusing.

[djmitche]

In this scenario, would cmd/vet be using x/tools/go/analysis/vet.Suite?

[adonovan]

In this scenario, would cmd/vet be using x/tools/go/analysis/vet.Suite?

Yes, but it would vendor x/tools periodically, so the vet.Suite variable represents "the set of analyzers in the upcoming Go release, give or take". I think it would probably work out fine in practice, but @prattmic is right that it can never be consistent.

[adonovan]

One alternative would be to expose the suite as a map (keyed by name) so that it's easy to remove or overwrite an entry, eliminating duplicates by construction.

Also: #71859 is a plan to make go fix a companion tool to go vet, where the latter prints diagnostics and the former applies fixes. We should expose the fix suite as well, for similar reasons, perhaps as fix.Suite, using a separate package to avoid unnecessarily aggregating dependencies.