Problem
clippy organizes lints into groups (correctness, style, complexity, perf, pedantic) with severity levels (warn/deny), letting users enable and tune whole families of rules. complexipy currently treats every rule the same: all are reported and all feed the exit code.
The idea
Group rules and let users enable/disable or raise whole groups at once — e.g. --group complexity --deny or --allow readability — rather than naming rules one by one. Every rule already carries a category (Complexity | Readability), so a first cut could reuse it as the group.
Open questions
- What groups make sense: reuse the existing
RuleCategory or introduce clippy-style groups (correctness/style/complexity/perf/pedantic)?
- Should severity levels map to exit codes (
deny fails the run), and how do they interact with --max-complexity-allowed?
- Should this ship together with per-rule suppression (a shared rule-selection mechanism) or independently?
Acceptance criteria (draft)
- A whole group can be enabled, disabled, or raised to deny with one flag.
- Severity changes are reflected in output and exit-code behaviour.
- Documented in the usage guide (EN + ES).
Problem
clippy organizes lints into groups (correctness, style, complexity, perf, pedantic) with severity levels (warn/deny), letting users enable and tune whole families of rules. complexipy currently treats every rule the same: all are reported and all feed the exit code.
The idea
Group rules and let users enable/disable or raise whole groups at once — e.g.
--group complexity --denyor--allow readability— rather than naming rules one by one. Every rule already carries a category (Complexity | Readability), so a first cut could reuse it as the group.Open questions
RuleCategoryor introduce clippy-style groups (correctness/style/complexity/perf/pedantic)?denyfails the run), and how do they interact with--max-complexity-allowed?Acceptance criteria (draft)