Allow selecting rules with severity warning in preview#23846
Allow selecting rules with severity warning in preview#23846
warning in preview#23846Conversation
|
7e2e587 to
7c9514a
Compare
33fdbb8 to
cb221a4
Compare
fd38c83 to
42d047a
Compare
cb221a4 to
e11289c
Compare
This is just the "aesthetic" part of implementing `warning` severities. Configuration changes are in #23846 It's expected that the `preview` ecosystem check times out here.
16f5460 to
cd03169
Compare
| { | ||
| warn_user_once!( | ||
| "Enabling rules with severity 'warning' requires preview mode, otherwise all rules are interpreted with severity 'error'." | ||
| ); | ||
| } |
There was a problem hiding this comment.
I'd love feedback on whether or not this should be the behavior when preview is not enabled. Another option would be to interpret everything "correctly" but just warn the user that severities are in preview and experimental.
If we do like the idea of interpreting these as error there's some other design questions... for example, at the moment with preview disabled it will still "correctly" populate lint.warn if you do --show-settings. Is that we want?
| /// Maps rule codes to a boolean indicating if the rule should be fixed. | ||
| enabled: RuleSet, | ||
| warn: RuleSet, | ||
| should_fix: RuleSet, |
There was a problem hiding this comment.
I think I'm implicitly assuming that warn is a subset of enabled. I believe this invariant is ensured because the public methods that mess with these fields do the right thing (e.g. RuleTable::warn below). But let me know if there's a better way to enforce this / organize this...
| // Override warnings of weaker specificity | ||
| // For example: | ||
| // ``` | ||
| // select = ["F401"] | ||
| // warn = ["F"] | ||
| // ``` | ||
| // should warn on all Pyflakes rules | ||
| // except for `F401` where it should error. | ||
| warn_map_updates.insert(rule, false); |
There was a problem hiding this comment.
This prevents a bunch of the strange behavior we brought up in design discussions.
|
I think this is ready for the first round of review. Probably most important is to see:
Of course suggestions on improving the actual implementation are also welcome! |
warning in previewwarning in preview
MichaReiser
left a comment
There was a problem hiding this comment.
I skimmed over the CLI tests and most output does make sense. I do think that the schema overall is a bit complicated to grasp what's going on, especially if nested configurations come into play. It's also easier to accidentially list a rule twice.
I wonder if we should take a step back and discuss how we want to role out human-readable names. For example, we could use the absence of select, extend-select, ignore and extend-ignore as opt-in to human readable names so that Ruff keeps using rule-codes in its output unless a user opted in to the new configuration (because they don't have a configuration or don't select any rules or use the new configuration schema).
What would be interesting to understand is if there are cases where we think a rule-table is less intuitive than todays select/warn/ignore.
| success: false | ||
| exit_code: 1 | ||
| ----- stdout ----- | ||
| try.py:1:8: error[F401] [*] `os` imported but unused |
There was a problem hiding this comment.
We should also test that some other F rule now has warning severity
| ----- stderr ----- | ||
| "### | ||
| ); | ||
| Ok(()) |
There was a problem hiding this comment.
Can you add some more tests demonstrating:
extend-*combinations. Especially combinations ofextend-and non-extendconfigurations- How
selectbehaves when there are rules that default to warning severity.
| /// Maps rule codes to a boolean indicating if the rule should be fixed. | ||
| enabled: RuleSet, | ||
| warn: RuleSet, | ||
| should_fix: RuleSet, |
| r#" | ||
| [lint] | ||
| preview = true | ||
| select = ["F401"] |
There was a problem hiding this comment.
Can you add a test that demonstrates the opposite: The outer configuration warning about F401 and the nested configuration selecting F401
|
I hope it's okay if I put this back to draft or is there something you want feedback on? |
This PR allows users to specify a set of rules to enable with severity level
warning(inpreview).They may do so in the CLI using
--warnand--extend-warnor in a configuration file viaCloses #1256
Details on Resolving the Configuration
The precedence between
selectandignore, within a configuration file, is as follows:--warn F --select F401will give all Pyflakes diagnostics exceptF401a severity ofwarning, and giveF401a severity oferror.warntakes precedence overselect, e.g.--select F401 --warn F401will resolve to--warn F401.As in the case of
selectvsextend-select, specifyingwarn = [...]will overwrite any inherited configuration forwarn. However, it will not overwrite an inherited configuration forselect.For example,
ruff check --warn ARG ex.pywill return diagnostics for all default rules with
errorseverity and then also theARGrules with severitywarning.In order to warn on a single rule, the user has to do something like this:
ruff check --select ARG --warn ARG ex.pywhich looks a bit funny.