-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: x/tools/go/analysis: add -category=... filter flag to driver commands #72008
Comments
Definitely agree. I recently tried I think it should have a "safe" and "unsafe" meta-category similar to ruff (https://docs.astral.sh/ruff/linter/#fix-safety). Safe fixes should be throughly tested and never ever break code. |
None of the categories of fix should ever break code; we regard all those problems as bugs and will fix them. Modernizers are all intended to be "safe" by the ruff classification. But the highest priority bugs are those that don't break the build or even the tests, as those problems are most likely to be overlooked. |
Right, thats a good stance too. If a fix is known to break code, it's better to either fix or remove it instead of labeling it "unsafe". |
Change https://go.dev/cl/655555 mentions this issue: |
Unfortunately this very tiny change affects the CLI of cmd/vet and other analysis tools and so requires a proposal, which will add at least a month to the time to merge the (generously contributed) fix. I will try to use this as an opportunity to streamline the proposal process for tiny changes. @aclements |
Change https://go.dev/cl/655436 mentions this issue: |
Thanks, happy to see (though the cherry pick below will just close it again...) |
Change https://go.dev/cl/655956 mentions this issue: |
Oops, thanks; reopening. |
Background: Some analysis tools produce a range of diagnostics and fixes and it would be useful to filter them before applying fixes. For example, the modernize analyzer produces a dozen different kinds of fix, and several users have reported that it is easier to review changes if they first batch-apply only the (numerous)
interface{}
->any
fixes in a single very low-risk CL that can be rubberstamped, and then apply all the other fixes in a smaller CL that needs to be properly reviewed (for example, because sometimes a valuable comments may be lost).Proposal: I propose we add a -category flag that accepts a comma-separated list of categories (or negated list of categories) and then applies only that set (or its complement).
The text was updated successfully, but these errors were encountered: