Repository navigation
proposal: cmd/go: fix: include selected staticcheck analyzers #76918
Description
Background: The staticcheck suite includes hundreds of high-quality analyzers, many appropriate for either go vet (which diagnoses mistakes) or go fix (which applies safe fixes to mistakes or benign style issues), or both. Many of staticcheck's analyzers, a hand-curated subset of slightly more than half, have been enabled in gopls for a while.
Some of them are synergistic with analyzers already in go fix: for example, go fix's stringsbuilder replaces a loop around s += fmt.Sprintf(...) by use of a stringsbuilder, such as s.WriteString(fmt.Sprintf(...)). Staticcheck's QF1012 analyzer then simplifies this to fmt.Fprintf(&s, ...), which is both better style and more efficient. Running just the go fix analyzers without the staticcheck analyzers may result in fixes that feel incomplete.
Proposal: We propose to incorporate a subset of staticcheck's analyzers in go vet and/or go fix. Rather than list hundreds of specific analyzers, we should decide based on policy criteria: those added to go vet should report mistakes with high precision, and those added to go fix should suggest fixes that are safe to apply. (These are the same criteria used in gopls.) The new packages would be vendored into GOROOT/src/cmd/vendor/honnef.co/go/tools.
Activity
gabyhelp commentedon Dec 18, 2025
Related Issues
Related Discussions
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
dominikh commentedon Dec 18, 2025
@adonovan do vet and/or fix get to use analyzers that use
go/ssa, and if so, what would the stance ongo/irbe?adonovan commentedon Dec 18, 2025
Good question; I should have mentioned this among the criteria. Currently no analyzers in cmd/vet or fix depend on go/ssa. I think the reason was a combination of memory usage and worries about version skew and/or bootstrapping of new frontend features; see #59714 (comment).
(Gopls is not bound by those constraints, so it does include x/tools/go/ssa-based analyzers. However, gopls does not include any ir-based analyzers because the buildir analyzer uses "facts" to improve the precision of the control-flow graph, and that requires it to be run recursively on all dependencies, which was observed to be costly. By contrast, buildssa does not use facts, though it does depend on ctrlflow, which does use facts to achieve the same improvements in CFG precision, but is much cheaper.)
I think we should maintain (and document) the rule that the go vet|fix suites depend on neither x/tools/go/ssa nor ir.
gopherbot commentedon Dec 19, 2025
Change https://go.dev/cl/731440 mentions this issue:
go/analysis/passes/modernize: document stringsbuilder/QF1012 synergygo/analysis/passes/modernize: document stringsbuilder/QF1012 synergy