bjoernager/rust
bjoernager/rust
1
Fork 0
Code Activity

More text fixes after Test section was moved to top

Browse source
This commit is contained in:
Philipp Hansch 2019-03-03 09:50:56 +01:00
parent 0da3521eb6
commit 23f3256e96
No known key found for this signature in database
GPG key ID: B6FA06A6E0E2665B
1 changed files with 17 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

32
doc/adding_lints.md
View file

@ -78,7 +78,7 @@ fn main() {
Now we can run the test with `TESTNAME=ui/foo_functions cargo uitest`. Now we can run the test with `TESTNAME=ui/foo_functions cargo uitest`.
Currently this test will fail. If you go through the output you will see that we Currently this test will fail. If you go through the output you will see that we
have to add some missing imports to our lint file. are told that `clippy::foo_functions` is an unknown lint, which is expected.
While you are working on implementing your lint, you can keep running the UI While you are working on implementing your lint, you can keep running the UI
test. That allows you to check if the output is turning into what you want. test. That allows you to check if the output is turning into what you want.
@ -97,16 +97,16 @@ that test. Rustfix will apply the suggestions from the lint to the code of the
test file and compare that to the contents of a `.fixed` file. test file and compare that to the contents of a `.fixed` file.
Use `tests/ui/update-all-references.sh` to automatically generate the Use `tests/ui/update-all-references.sh` to automatically generate the
`.fixed` file after running `cargo test`. `.fixed` file after running the tests.
With tests in place, let's have a look at implementing our lint now. With tests in place, let's have a look at implementing our lint now.
### Testing manually ### Testing manually
Manually testing against an example file is useful if you have added some Manually testing against an example file can be useful if you have added some
`println!`s and test suite output becomes unreadable. To try Clippy with your `println!`s and the test suite output becomes unreadable. To try Clippy with
local modifications, run `env CLIPPY_TESTS=true cargo run --bin clippy-driver -- -L ./target/debug input.rs` your local modifications, run `env CLIPPY_TESTS=true cargo run --bin
from the working copy root. clippy-driver -- -L ./target/debug input.rs` from the working copy root.
### Lint declaration ### Lint declaration
@ -177,9 +177,9 @@ in `clippy_lints/src/lib.rs`:
reg.register_early_lint_pass(box foo_functions::FooFunctionsPass); reg.register_early_lint_pass(box foo_functions::FooFunctionsPass);
``` ```
Without that, running the UI tests would produce an error like `unknown clippy This should fix the `unknown clippy lint: clippy::foo_functions` error that we
lint: clippy::foo_functions`. The next decision we have to make is which lint saw when we executed our tests the first time. The next decision we have to make
pass our lint is going to need. is which lint pass our lint is going to need.
### Lint passes ### Lint passes
@ -189,8 +189,6 @@ This is good, because it makes writing this particular lint less complicated.
We have to make this decision with every new Clippy lint. It boils down to using We have to make this decision with every new Clippy lint. It boils down to using
either [`EarlyLintPass`][early_lint_pass] or [`LateLintPass`][late_lint_pass]. either [`EarlyLintPass`][early_lint_pass] or [`LateLintPass`][late_lint_pass].
This is a result of Rust's compilation process. You can read more about it [in
the rustc guide][compilation_stages].
In short, the `LateLintPass` has access to type information while the In short, the `LateLintPass` has access to type information while the
`EarlyLintPass` doesn't. If you don't need access to type information, use the `EarlyLintPass` doesn't. If you don't need access to type information, use the
@ -209,8 +207,7 @@ use rustc::{declare_tool_lint, lint_array};
### Emitting a lint ### Emitting a lint
With UI tests and the lint declaration in place, we can start working on the With UI tests and the lint declaration in place, we can start working on the
implementation of the lint logic. We can keep executing the tests until we make implementation of the lint logic.
them pass.
Let's start by implementing the `EarlyLintPass` for our `FooFunctionsPass`: Let's start by implementing the `EarlyLintPass` for our `FooFunctionsPass`:
@ -229,9 +226,12 @@ the next section. Let's worry about the details later and emit our lint for
*every* function definition first. *every* function definition first.
Depending on how complex we want our lint message to be, we can choose from a Depending on how complex we want our lint message to be, we can choose from a
variety of lint emission functions. They can all be found in variety of lint emission functions. They can all be found in
[`clippy_lints/src/utils/diagnostics.rs`][diagnostics]. [`clippy_lints/src/utils/diagnostics.rs`][diagnostics].
`span_help_and_lint` seems most appropriate in this case. It allows us to
provide an extra help message and we can't really suggest a better name
automatically. This is how it looks:
```rust ```rust
impl EarlyLintPass for Pass { impl EarlyLintPass for Pass {
@ -247,9 +247,11 @@ impl EarlyLintPass for Pass {
} }
``` ```
Running our UI test should now produce output that contains the lint message.
### Adding the lint logic ### Adding the lint logic
Writing the logic for your lint will most likely be different from this example, Writing the logic for our lint will most likely be different from this example,
so this section is kept rather short. so this section is kept rather short.
Using the [`check_fn`][check_fn] method gives us access to [`FnKind`][fn_kind] Using the [`check_fn`][check_fn] method gives us access to [`FnKind`][fn_kind]