Unused lint does not rewrite suppressed warnings #24055
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #24009
Why was the ticket worth tackling?
Lints are inherently imprecise (the "unused" lint, in particular, runs after typer and merely infers usages), so that it is necessary to provide mechanisms to "suppress" them, namely
-Wconf
and@nowarn
. Even if a lint warning is correct, it may not be helpful. For example, the user may want to retain certain unused imports so that they are always available (Decorators
) and so that the file "header" isn't subject to repeated edits or reformatting. (See-Yimports
.)But it's also important to address warnings, so that
-rewrite
might be enabled "by default" and not only for one-off migrations for which manual edits are expected.Therefore it should be possible to selectively apply rewrites proposed by linters.
Otherwise, linting and rewriting are much less useful.
How I fixed it
It is natural not to rewrite lints that are suppressed. Only "unused imports" emits "code actions" under
-rewrite
, so the lint was improved to avoid adding actions ifctx.run.suppressions
(for@nowarn
) or-Wconf
say that the warning won't be reported. That mechanism is imprecise, so this filter is moved directly to the reporter (when it reports), which applies actions forLintWarning
only.CheckUnused
is tweaked to emit onlyLintWarning
, with the additional tweak that anorigin
can be a distinguished value to meanNoOrigin
. (The origin is just a string, alas, subject to an arbitrary regex pattern match.) It is also tweaked to always calculate the code action. As suggested by a previous reviewer (@tgodzik I presume), this makes the action available to tooling. (The imports rewrite was conceived as a quick internal tool and not as a general code formatter. Used interactively, that may be more convenient, but I haven't tried it.)Why is this PR worth reviewing?
Certain components emit rewrites directly; for example, the parser might test certain conditions (such as migration), warn about deprecated syntax, and then add a rewrite to contemporary syntax. This PR offers a path toward a more general mechanism: emit a diagnostic with an associated action, and let the user control whether to see the diagnostic and therefore whether to apply the action under
-rewrite
.This PR turns out to be more complex in UX than in code.
What's the worse that could happen?
The import action code in
CheckUnused
is no longer gated by-rewrite
, which may be acceptable.