* [Running test suite](#running-test-suite)
* [Running rustfmt](#running-rustfmt)
* [Testing manually](#testing-manually)
- * [Linting Clippy with your local changes](#linting-clippy-with-your-local-changes)
- * [How Clippy works](#how-clippy-works)
- * [Fixing nightly build failures](#fixing-build-failures-caused-by-rust)
+* [How Clippy works](#how-clippy-works)
+* [Fixing nightly build failures](#fixing-build-failures-caused-by-rust)
+* [Issue and PR Triage](#issue-and-pr-triage)
+* [Bors and Homu](#bors-and-homu)
* [Contributions](#contributions)
## Getting started
label can be used to find the easy issues. If you want to work on an issue, please leave a comment
so that we can assign it to you!
+There are also some abandoned PRs, marked with
+[`S-inactive-closed`](https://github.com/rust-lang/rust-clippy/pulls?q=is%3Aclosed+label%3AS-inactive-closed).
+Pretty often these PRs are nearly completed and just need some extra steps
+(formatting, addressing review comments, ...) to be merged. If you want to
+complete such a PR, please leave a comment in the PR and open a new one based
+on it.
+
Issues marked [`T-AST`](https://github.com/rust-lang/rust-clippy/labels/T-AST) involve simple
matching of the syntax tree structure, and are generally easier than
[`T-middle`](https://github.com/rust-lang/rust-clippy/labels/T-middle) issues, which involve types
## Writing code
+Clippy depends on the current git master version of rustc, which can change rapidly. Make sure you're
+working near rust-clippy's master, and use the `setup-toolchain.sh` script to configure the appropriate
+toolchain for this directory.
+
[Llogiq's blog post on lints](https://llogiq.github.io/2015/06/04/workflows.html) is a nice primer
to lint-writing, though it does get into advanced stuff. Most lints consist of an implementation of
`LintPass` with one or more of its default methods overridden. See the existing lints for examples
of this.
If you want to add a new lint or change existing ones apart from bugfixing, it's
-also a good idea to give the [stability guaratees][rfc_stability] and
+also a good idea to give the [stability guarantees][rfc_stability] and
[lint categories][rfc_lint_cats] sections of the [Clippy 1.0 RFC][clippy_rfc] a
quick read.
}
```
-Now you run `TESTNAME=ui/my_lint cargo test --test compile-test` to produce
+Now you run `TESTNAME=ui/my_lint cargo uitest` to produce
a `.stdout` file with the generated code:
```rust
/// ```
```
-Once your lint is merged it will show up in the [lint list](https://rust-lang-nursery.github.io/rust-clippy/master/index.html)
+Once your lint is merged it will show up in the [lint list](https://rust-lang.github.io/rust-clippy/master/index.html)
### Running test suite
If you don't want to wait for all tests to finish, you can also execute a single test file by using `TESTNAME` to specify the test to run:
```bash
-TESTNAME=ui/empty_line_after_outer_attr cargo test --test compile-test
+TESTNAME=ui/empty_line_after_outer_attr cargo uitest
```
Clippy uses UI tests. UI tests check that the output of the compiler is exactly as expected.
`cargo test`) and check whether the output looks as you expect with `git diff`. Commit all
`*.stderr` files, too.
+If the lint you are working on is making use of structured suggestions, the
+test file should include a `// run-rustfix` comment at the top. This will
+additionally run [rustfix](https://github.com/rust-lang-nursery/rustfix) for
+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.
+
+Use `tests/ui/update-all-references.sh` to automatically generate the
+`.fixed` file after running `cargo test`.
+
### Running rustfmt
[Rustfmt](https://github.com/rust-lang/rustfmt) is a tool for formatting Rust code according
It can be installed via `rustup`:
```bash
-rustup component add rustfmt-preview
+rustup component add rustfmt
```
Use `cargo fmt --all` to format the whole codebase.
local modifications, run `env CLIPPY_TESTS=true cargo run --bin clippy-driver -- -L ./target/debug input.rs`
from the working copy root.
-### Linting Clippy with your local changes
-
-Clippy CI only passes if all lints defined in the version of the Clippy being
-tested pass (that is, don’t report any suggestions). You can avoid prolonging
-the CI feedback cycle for PRs you submit by running these lints yourself ahead
-of time and addressing any issues found:
-
-```
-cargo build
-`pwd`/target/debug/cargo-clippy clippy --all-targets --all-features -- -D clippy::all -D clippy::internal -D clippy::pedantic
-```
-
-### How Clippy works
+## How Clippy works
Clippy is a [rustc compiler plugin][compiler_plugin]. The main entry point is at [`src/lib.rs`][main_entry]. In there, the lint registration is delegated to the [`clippy_lints`][lint_crate] crate.
That's why the `else_if_without_else` example uses the `register_early_lint_pass` function. Because the [actual lint logic][else_if_without_else] does not depend on any type information.
-### Fixing build failures caused by Rust
+## Fixing build failures caused by Rust
-Clippy will sometimes break because it still depends on unstable internal Rust features. Most of the times we have to adapt to the changes and only very rarely there's an actual bug in Rust. Fixing build failures caused by Rust updates, can be a good way to learn about Rust internals.
+Clippy will sometimes fail to build from source because building it depends on unstable internal Rust features. Most of the times we have to adapt to the changes and only very rarely there's an actual bug in Rust. Fixing build failures caused by Rust updates, can be a good way to learn about Rust internals.
In order to find out why Clippy does not work properly with a new Rust commit, you can use the [rust-toolstate commit history][toolstate_commit_history].
You will then have to look for the last commit that contains `test-pass -> build-fail` or `test-pass` -> `test-fail` for the `clippy-driver` component. [Here][toolstate_commit] is an example.
cargo test
```
+## Issue and PR triage
+
+Clippy is following the [Rust triage procedure][triage] for issues and pull
+requests.
+
+However, we are a smaller project with all contributors being volunteers
+currently. Between writing new lints, fixing issues, reviewing pull requests and
+responding to issues there may not always be enough time to stay on top of it
+all.
+
+Our highest priority is fixing [crashes][l-crash] and [bugs][l-bug]. We don't
+want Clippy to crash on your code and we want it to be as reliable as the
+suggestions from Rust compiler errors.
+
+## Bors and Homu
+
+We use a bot powered by [Homu][homu] to help automate testing and landing of pull
+requests in Clippy. The bot's username is @bors.
+
+You can find the Clippy bors queue [here][homu_queue].
+
+If you have @bors permissions, you can find an overview of the available
+commands [here][homu_instructions].
+
+
## Contributions
Contributions to Clippy should be made in the form of GitHub pull requests. Each pull request will
[clippy_rfc]: https://github.com/rust-lang/rfcs/blob/master/text/2476-clippy-uno.md
[rfc_stability]: https://github.com/rust-lang/rfcs/blob/master/text/2476-clippy-uno.md#stability-guarantees
[rfc_lint_cats]: https://github.com/rust-lang/rfcs/blob/master/text/2476-clippy-uno.md#lint-audit-and-categories
+[triage]: https://forge.rust-lang.org/triage-procedure.html
+[l-crash]: https://github.com/rust-lang/rust-clippy/labels/L-crash%20%3Aboom%3A
+[l-bug]: https://github.com/rust-lang/rust-clippy/labels/L-bug%20%3Abeetle%3A
+[homu]: https://github.com/servo/homu
+[homu_instructions]: https://buildbot2.rust-lang.org/homu/
+[homu_queue]: https://buildbot2.rust-lang.org/homu/queue/clippy
projects / rust.git / blobdiff