Skip to content

Commit f516d47

Browse files
authored
Update contributing guide for adding a new rule (#22779)
Summary -- This is a follow-up to #21035 and #22732 to update the contribution guide for adding a new rule for the changes to the `violation_metadata` attribute and also to how we emit diagnostics. Test Plan -- Built and viewed the docs locally to make sure they render correctly
1 parent 53962dc commit f516d47

1 file changed

Lines changed: 8 additions & 5 deletions

File tree

CONTRIBUTING.md

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -160,7 +160,10 @@ At a high level, the steps involved in adding a new lint rule are as follows:
160160
1. Create a file for your rule (e.g., `crates/ruff_linter/src/rules/flake8_bugbear/rules/assert_false.rs`).
161161

162162
1. In that file, define a violation struct (e.g., `pub struct AssertFalse`). You can grep for
163-
`#[derive(ViolationMetadata)]` to see examples.
163+
`#[derive(ViolationMetadata)]` to see examples. You also need to add a
164+
`#[violation_metadata(preview_since = "NEXT_RUFF_VERSION")]` attribute on your
165+
`ViolationMetadata` struct. This adds the rule in preview, and the version will be filled in
166+
automatically in the next release.
164167

165168
1. In that file, define a function that adds the violation to the diagnostic list as appropriate
166169
(e.g., `pub(crate) fn assert_false`) based on whatever inputs are required for the rule (e.g.,
@@ -174,8 +177,7 @@ At a high level, the steps involved in adding a new lint rule are as follows:
174177
statements, like imports) or `analyze/expression.rs` (if your rule is based on analyzing
175178
expressions, like function calls).
176179

177-
1. Map the violation struct to a rule code in `crates/ruff_linter/src/codes.rs` (e.g., `B011`). New rules
178-
should be added in `RuleGroup::Preview`.
180+
1. Map the violation struct to a rule code in `crates/ruff_linter/src/codes.rs` (e.g., `B011`).
179181

180182
1. Add proper [testing](#rule-testing-fixtures-and-snapshots) for your rule.
181183

@@ -186,8 +188,9 @@ to call your new function at the appropriate time and with the appropriate input
186188
defined therein is a Python AST visitor, which iterates over the AST, building up a semantic model,
187189
and calling out to lint rule analyzer functions as it goes.
188190

189-
If you need to inspect the AST, you can run `cargo dev print-ast` with a Python file. Grep
190-
for the `Diagnostic::new` invocations to understand how other, similar rules are implemented.
191+
If you need to inspect the AST, you can run `cargo dev print-ast` with a Python file or use the AST
192+
panel in the [playground](https://play.ruff.rs/?secondary=AST). Grep for the
193+
`Checker::report_diagnostic` invocations to understand how other, similar rules are implemented.
191194

192195
Once you're satisfied with your code, add tests for your rule
193196
(see: [rule testing](#rule-testing-fixtures-and-snapshots)), and regenerate the documentation and

0 commit comments

Comments
 (0)