x/tools/go/analysis/passes/modernize: publish

[adonovan]

Background: gopls has a couple dozen Analyzers that flag features of Go code that could be improved by using newer features of the languages and library, and that suggest fixes to do so. We would like to make this functionality available in go fix (see #71859).

Proposal: we propose to move the x/tools/gopls/internal/modernize directory to x/tools/go/analysis/passes/modernize.

package modernize // import "golang.org/x/tools/go/passes/modernize"

// Suite lists all modernize analyzers that are safe to be enabled by default.
var Suite = []*analysis.Analyzer{
	AnyAnalyzer,
	// AppendClippedAnalyzer, // not nil-preserving!
	BLoopAnalyzer,
	FmtAppendfAnalyzer,
	ForVarAnalyzer,
	MapsLoopAnalyzer,
	MinMaxAnalyzer,
	OmitZeroAnalyzer,
	RangeIntAnalyzer,
	SlicesContainsAnalyzer,
	// SlicesDeleteAnalyzer, // not nil-preserving!
	SlicesSortAnalyzer,
	StringsCutPrefixAnalyzer,
	StringsSeqAnalyzer,
	TestingContextAnalyzer,
	WaitGroupAnalyzer,
}

var (
	AnyAnalyzer,
	AppendClippedAnalyzer,
	BLoopAnalyzer,
	FmtAppendfAnalyzer,
	ForVarAnalyzer,
	MapsLoopAnalyzer,
	MinMaxAnalyzer,
	OmitZeroAnalyzer,
	RangeIntAnalyzer,
	SlicesContainsAnalyzer,
	SlicesDeleteAnalyzer,
	SlicesSortAnalyzer,
	StringsCutPrefixAnalyzer,
	StringsSeqAnalyzer,
	TestingContextAnalyzer,
	WaitGroupAnalyzer
	*analysis.Analyzer
)

[gabyhelp]

Related Issues

• proposal: x/tools/go/analysis/passes/inline: publish //go:fix inline analyzer #75267
• proposal: cmd/fix: apply fixes from modernizers and gofix analyzers #71859
• x/tools/gopls: warn about standard library API usage based on Go version #50689
• cmd/go: command (perhaps 'go fix') to apply all safe fixes #73623
• x/tools/gopls: remove convenience analyzers (cleanup) #61559 (closed)

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

[cespare]

At work we have an internal linter which is essentially just all the vet passes that we want to enable (including some that aren't go vet defaults) plus a handful of custom, internal passes. This is all glued together with multichecker.Main. Doing it this way makes it easier to have fine-tuned control over the vet checks and also is more efficient because it reduces duplicated work on the common analyses that need to happen for all these different passes.

Anyway, I'm happy to see this change because it will let us put some of the modernize checks into our linter too. We've been doing some modernization passes on an ad hoc basis but haven't yet figured out whether/how we want to lock in these changes into our automatically-enforced regime.

More generally: it's great when all Analyzer passes that are used by the tools you folks write are exported for use elsewhere.

[adonovan]

Anyway, I'm happy to see this change because it will let us put some of the modernize checks into our linter too. We've been doing some modernization passes on an ad hoc basis but haven't yet figured out whether/how we want to lock in these changes into our automatically-enforced regime.

More generally: it's great when all Analyzer passes that are used by the tools you folks write are exported for use elsewhere.

Glad to hear it, this completely aligns with my thinking. There is a recent proposal (#75227) to expose a global variable that defines "the list of analyzers actually used by go vet", which I think is another good step in that direction. We'll likely want an analogous one for "used by go fix" in light of #71859.

[gopherbot]

Change https://go.dev/cl/701775 mentions this issue: internal/moreiters: move from gopls/internal/util/moreiters

[gopherbot]

Change https://go.dev/cl/701776 mentions this issue: internal/analysisinternal/generated: move from gopls/internal/analysis

[gopherbot]

Change https://go.dev/cl/701777 mentions this issue: internal/astutil: move declarations from gopls/internal/util/astutil