mirror of
https://github.com/rust-lang/rust-clippy
synced 2024-11-10 07:04:18 +00:00
Gramar, and spelin kleanup
A few minor cleanups in various markdown files, mostly focusing on spelling and ignoring non-compilable codeblocks.
This commit is contained in:
parent
d43714a101
commit
41b367fa5f
21 changed files with 75 additions and 75 deletions
|
@ -11,7 +11,7 @@ Lints are divided into categories, each with a default [lint level](https://doc.
|
|||
You can choose how much Clippy is supposed to ~~annoy~~ help you by changing the lint level by category.
|
||||
|
||||
| Category | Description | Default level |
|
||||
| --------------------- | ----------------------------------------------------------------------------------- | ------------- |
|
||||
|-----------------------|-------------------------------------------------------------------------------------|---------------|
|
||||
| `clippy::all` | all lints that are on by default (correctness, suspicious, style, complexity, perf) | **warn/deny** |
|
||||
| `clippy::correctness` | code that is outright wrong or useless | **deny** |
|
||||
| `clippy::suspicious` | code that is most likely wrong or useless | **warn** |
|
||||
|
@ -130,7 +130,7 @@ for example.
|
|||
|
||||
You can add Clippy to Travis CI in the same way you use it locally:
|
||||
|
||||
```yml
|
||||
```yaml
|
||||
language: rust
|
||||
rust:
|
||||
- stable
|
||||
|
@ -253,7 +253,7 @@ rust-version = "1.30"
|
|||
|
||||
The MSRV can also be specified as an attribute, like below.
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
#![feature(custom_inner_attributes)]
|
||||
#![clippy::msrv = "1.30.0"]
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ much Clippy is supposed to ~~annoy~~ help you by changing the lint level by
|
|||
category.
|
||||
|
||||
| Category | Description | Default level |
|
||||
| --------------------- | ----------------------------------------------------------------------------------- | ------------- |
|
||||
|-----------------------|-------------------------------------------------------------------------------------|---------------|
|
||||
| `clippy::all` | all lints that are on by default (correctness, suspicious, style, complexity, perf) | **warn/deny** |
|
||||
| `clippy::correctness` | code that is outright wrong or useless | **deny** |
|
||||
| `clippy::suspicious` | code that is most likely wrong or useless | **warn** |
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
> **Note:** The configuration file is unstable and may be deprecated in the future.
|
||||
|
||||
Some lints can be configured in a TOML file named `clippy.toml` or `.clippy.toml`. It contains a
|
||||
basic `variable = value` mapping eg.
|
||||
basic `variable = value` mapping e.g.
|
||||
|
||||
```toml
|
||||
avoid-breaking-exported-api = false
|
||||
|
@ -60,7 +60,7 @@ And to warn on `lint_name`, run
|
|||
cargo clippy -- -W clippy::lint_name
|
||||
```
|
||||
|
||||
This also works with lint groups. For example you can run Clippy with warnings for all lints enabled:
|
||||
This also works with lint groups. For example, you can run Clippy with warnings for all lints enabled:
|
||||
|
||||
```terminal
|
||||
cargo clippy -- -W clippy::pedantic
|
||||
|
@ -84,7 +84,7 @@ msrv = "1.30.0"
|
|||
|
||||
The MSRV can also be specified as an attribute, like below.
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
#![feature(custom_inner_attributes)]
|
||||
#![clippy::msrv = "1.30.0"]
|
||||
|
||||
|
@ -96,7 +96,7 @@ fn main() {
|
|||
You can also omit the patch version when specifying the MSRV, so `msrv = 1.30`
|
||||
is equivalent to `msrv = 1.30.0`.
|
||||
|
||||
Note: `custom_inner_attributes` is an unstable feature so it has to be enabled explicitly.
|
||||
Note: `custom_inner_attributes` is an unstable feature, so it has to be enabled explicitly.
|
||||
|
||||
Lints that recognize this configuration option can be
|
||||
found [here](https://rust-lang.github.io/rust-clippy/master/index.html#msrv)
|
||||
|
|
|
@ -5,7 +5,7 @@ making Clippy better by contributing to it. In that case, welcome to the
|
|||
project!
|
||||
|
||||
> _Note:_ If you're just interested in using Clippy, there's nothing to see from
|
||||
> this point onward and you should return to one of the earlier chapters.
|
||||
> this point onward, and you should return to one of the earlier chapters.
|
||||
|
||||
## Getting started
|
||||
|
||||
|
|
|
@ -24,7 +24,7 @@ because that's clearly a non-descriptive name.
|
|||
- [Lint passes](#lint-passes)
|
||||
- [Emitting a lint](#emitting-a-lint)
|
||||
- [Adding the lint logic](#adding-the-lint-logic)
|
||||
- [Specifying the lint's minimum supported Rust version (MSRV)](#specifying-the-lints-minimum-supported-rust-version-msrv)
|
||||
- [Specifying the lint's minimum supported Rust version (MSRV)](#specifying-the-lints-minimum-supported-rust-version--msrv-)
|
||||
- [Author lint](#author-lint)
|
||||
- [Print HIR lint](#print-hir-lint)
|
||||
- [Documentation](#documentation)
|
||||
|
@ -275,7 +275,7 @@ When declaring a new lint by hand and `cargo dev update_lints` is used, the lint
|
|||
pass may have to be registered manually in the `register_plugins` function in
|
||||
`clippy_lints/src/lib.rs`:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
store.register_early_pass(|| Box::new(foo_functions::FooFunctions));
|
||||
```
|
||||
|
||||
|
@ -301,7 +301,7 @@ either [`EarlyLintPass`][early_lint_pass] or [`LateLintPass`][late_lint_pass].
|
|||
|
||||
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`. The `EarlyLintPass` is also faster. However linting speed
|
||||
`EarlyLintPass`. The `EarlyLintPass` is also faster. However, linting speed
|
||||
hasn't really been a concern with Clippy so far.
|
||||
|
||||
Since we don't need type information for checking the function name, we used
|
||||
|
@ -318,7 +318,7 @@ implementation of the lint logic.
|
|||
|
||||
Let's start by implementing the `EarlyLintPass` for our `FooFunctions`:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
impl EarlyLintPass for FooFunctions {
|
||||
fn check_fn(&mut self, cx: &EarlyContext<'_>, fn_kind: FnKind<'_>, span: Span, _: NodeId) {
|
||||
// TODO: Emit lint here
|
||||
|
@ -337,10 +337,10 @@ variety of lint emission functions. They can all be found in
|
|||
[`clippy_utils/src/diagnostics.rs`][diagnostics].
|
||||
|
||||
`span_lint_and_help` seems most appropriate in this case. It allows us to
|
||||
provide an extra help message and we can't really suggest a better name
|
||||
provide an extra help message, and we can't really suggest a better name
|
||||
automatically. This is how it looks:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
impl EarlyLintPass for FooFunctions {
|
||||
fn check_fn(&mut self, cx: &EarlyContext<'_>, fn_kind: FnKind<'_>, span: Span, _: NodeId) {
|
||||
span_lint_and_help(
|
||||
|
@ -479,7 +479,7 @@ the value from `clippy.toml`. This can be accounted for using the
|
|||
`extract_msrv_attr!(LintContext)` macro and passing
|
||||
`LateContext`/`EarlyContext`.
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
impl<'tcx> LateLintPass<'tcx> for ManualStrip {
|
||||
fn check_expr(&mut self, cx: &LateContext<'tcx>, expr: &'tcx Expr<'_>) {
|
||||
...
|
||||
|
@ -493,7 +493,7 @@ the lint's test file, `tests/ui/manual_strip.rs` in this example. It should
|
|||
have a case for the version below the MSRV and one with the same contents but
|
||||
for the MSRV version itself.
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
...
|
||||
|
||||
#[clippy::msrv = "1.44"]
|
||||
|
@ -524,7 +524,7 @@ define_Conf! {
|
|||
|
||||
If you have trouble implementing your lint, there is also the internal `author`
|
||||
lint to generate Clippy code that detects the offending pattern. It does not
|
||||
work for all of the Rust syntax, but can give a good starting point.
|
||||
work for all the Rust syntax, but can give a good starting point.
|
||||
|
||||
The quickest way to use it, is the [Rust playground:
|
||||
play.rust-lang.org][author_example]. Put the code you want to lint into the
|
||||
|
@ -617,7 +617,7 @@ output in the `stdout` part.
|
|||
|
||||
## PR Checklist
|
||||
|
||||
Before submitting your PR make sure you followed all of the basic requirements:
|
||||
Before submitting your PR make sure you followed all the basic requirements:
|
||||
|
||||
<!-- Sync this with `.github/PULL_REQUEST_TEMPLATE` -->
|
||||
|
||||
|
@ -637,7 +637,7 @@ for some users. Adding a configuration is done in the following steps:
|
|||
|
||||
1. Adding a new configuration entry to [`clippy_lints::utils::conf`] like this:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
/// Lint: LINT_NAME.
|
||||
///
|
||||
/// <The configuration field doc comment>
|
||||
|
@ -690,7 +690,7 @@ for some users. Adding a configuration is done in the following steps:
|
|||
configuration value is now cloned or copied into a local value that is then
|
||||
passed to the impl struct like this:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
// Default generated registration:
|
||||
store.register_*_pass(|| box module::StructName);
|
||||
|
||||
|
|
|
@ -125,7 +125,7 @@ We follow a rustc no merge-commit policy. See
|
|||
## Common Abbreviations
|
||||
|
||||
| Abbreviation | Meaning |
|
||||
| ------------ | -------------------------------------- |
|
||||
|--------------|----------------------------------------|
|
||||
| UB | Undefined Behavior |
|
||||
| FP | False Positive |
|
||||
| FN | False Negative |
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
You may need following tooltips to catch up with common operations.
|
||||
|
||||
- [Common tools for writing lints](#common-tools-for-writing-lints)
|
||||
- [Retrieving the type of an expression](#retrieving-the-type-of-an-expression)
|
||||
- [Retrieving the type of expression](#retrieving-the-type-of-expression)
|
||||
- [Checking if an expr is calling a specific method](#checking-if-an-expr-is-calling-a-specific-method)
|
||||
- [Checking for a specific type](#checking-for-a-specific-type)
|
||||
- [Checking if a type implements a specific trait](#checking-if-a-type-implements-a-specific-trait)
|
||||
|
@ -16,7 +16,7 @@ Useful Rustc dev guide links:
|
|||
- [Type checking](https://rustc-dev-guide.rust-lang.org/type-checking.html)
|
||||
- [Ty module](https://rustc-dev-guide.rust-lang.org/ty.html)
|
||||
|
||||
## Retrieving the type of an expression
|
||||
## Retrieving the type of expression
|
||||
|
||||
Sometimes you may want to retrieve the type `Ty` of an expression `Expr`, for
|
||||
example to answer following questions:
|
||||
|
@ -45,7 +45,7 @@ impl LateLintPass<'_> for MyStructLint {
|
|||
}
|
||||
```
|
||||
|
||||
Similarly in [`TypeckResults`][TypeckResults] methods, you have the
|
||||
Similarly, in [`TypeckResults`][TypeckResults] methods, you have the
|
||||
[`pat_ty()`][pat_ty] method to retrieve a type from a pattern.
|
||||
|
||||
Two noticeable items here:
|
||||
|
@ -192,7 +192,7 @@ functions to deal with macros:
|
|||
- `span.from_expansion()`: detects if a span is from macro expansion or
|
||||
desugaring. Checking this is a common first step in a lint.
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
if expr.span.from_expansion() {
|
||||
// just forget it
|
||||
return;
|
||||
|
@ -203,11 +203,11 @@ functions to deal with macros:
|
|||
if so, which macro call expanded it. It is sometimes useful to check if the
|
||||
context of two spans are equal.
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
// expands to `1 + 0`, but don't lint
|
||||
1 + mac!()
|
||||
```
|
||||
```rust
|
||||
```rust,ignore
|
||||
if left.span.ctxt() != right.span.ctxt() {
|
||||
// the coder most likely cannot modify this expression
|
||||
return;
|
||||
|
@ -246,7 +246,7 @@ functions to deal with macros:
|
|||
`macro_rules!` with `a == $b`, `$b` is expanded to some expression with a
|
||||
different context from `a`.
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
macro_rules! m {
|
||||
($a:expr, $b:expr) => {
|
||||
if $a.is_some() {
|
||||
|
|
|
@ -13,7 +13,7 @@ guide to Clippy that you're reading right now. The Clippy book is formatted with
|
|||
While not strictly necessary since the book source is simply Markdown text
|
||||
files, having mdBook locally will allow you to build, test and serve the book
|
||||
locally to view changes before you commit them to the repository. You likely
|
||||
already have `cargo` installed, so the easiest option is to simply:
|
||||
already have `cargo` installed, so the easiest option is to:
|
||||
|
||||
```shell
|
||||
cargo install mdbook
|
||||
|
@ -26,7 +26,7 @@ instructions for other options.
|
|||
|
||||
The book's
|
||||
[src](https://github.com/rust-lang/rust-clippy/tree/master/book/src)
|
||||
directory contains all of the markdown files used to generate the book. If you
|
||||
directory contains all the markdown files used to generate the book. If you
|
||||
want to see your changes in real time, you can use the mdBook `serve` command to
|
||||
run a web server locally that will automatically update changes as they are
|
||||
made. From the top level of your `rust-clippy` directory:
|
||||
|
|
|
@ -101,7 +101,7 @@ Look for the [`beta-accepted`] label and make sure to also include the PRs with
|
|||
that label in the changelog. If you can, remove the `beta-accepted` labels
|
||||
**after** the changelog PR was merged.
|
||||
|
||||
> _Note:_ Some of those PRs might even got backported to the previous `beta`.
|
||||
> _Note:_ Some of those PRs might even get backported to the previous `beta`.
|
||||
> Those have to be included in the changelog of the _previous_ release.
|
||||
|
||||
### 4. Update `clippy::version` attributes
|
||||
|
|
|
@ -44,7 +44,7 @@ $ git push origin backport_remerge # This can be pushed to your fork
|
|||
```
|
||||
|
||||
After this, open a PR to the master branch. In this PR, the commit hash of the
|
||||
`HEAD` of the `beta` branch must exists. In addition to that, no files should be
|
||||
`HEAD` of the `beta` branch must exist. In addition to that, no files should be
|
||||
changed by this PR.
|
||||
|
||||
## Update the `beta` branch
|
||||
|
|
|
@ -47,7 +47,7 @@ sudo chown --reference=/usr/lib/git-core/git-subtree~ /usr/lib/git-core/git-subt
|
|||
|
||||
> _Note:_ If you are a Debian user, `dash` is the shell used by default for
|
||||
> scripts instead of `sh`. This shell has a hardcoded recursion limit set to
|
||||
> 1000. In order to make this process work, you need to force the script to run
|
||||
> 1,000. In order to make this process work, you need to force the script to run
|
||||
> `bash` instead. You can do this by editing the first line of the `git-subtree`
|
||||
> script and changing `sh` to `bash`.
|
||||
|
||||
|
@ -71,10 +71,10 @@ $ git remote add clippy-local /path/to/rust-clippy
|
|||
|
||||
## Performing the sync from [`rust-lang/rust`] to Clippy
|
||||
|
||||
Here is a TL;DR version of the sync process (all of the following commands have
|
||||
Here is a TL;DR version of the sync process (all the following commands have
|
||||
to be run inside the `rust` directory):
|
||||
|
||||
1. Clone the [`rust-lang/rust`] repository or make sure it is up to date.
|
||||
1. Clone the [`rust-lang/rust`] repository or make sure it is up-to-date.
|
||||
2. Checkout the commit from the latest available nightly. You can get it using
|
||||
`rustup check`.
|
||||
3. Sync the changes to the rust-copy of Clippy to your Clippy fork:
|
||||
|
@ -107,7 +107,7 @@ to be run inside the `rust` directory):
|
|||
|
||||
## Performing the sync from Clippy to [`rust-lang/rust`]
|
||||
|
||||
All of the following commands have to be run inside the `rust` directory.
|
||||
All the following commands have to be run inside the `rust` directory.
|
||||
|
||||
1. Make sure you have checked out the latest `master` of `rust-lang/rust`.
|
||||
2. Sync the `rust-lang/rust-clippy` master to the rust-copy of Clippy:
|
||||
|
|
|
@ -6,6 +6,6 @@ or around Clippy in the long run.
|
|||
Besides adding more and more lints and improve the lints that Clippy already
|
||||
has, Clippy is also interested in making the experience of its users, developers
|
||||
and maintainers better over time. Projects that address bigger picture things
|
||||
like this usually take more time and it is useful to have a proposal for those
|
||||
like this usually take more time, and it is useful to have a proposal for those
|
||||
first. This is the place where such proposals are collected, so that we can
|
||||
refer to them when working on them.
|
||||
|
|
|
@ -52,8 +52,8 @@ In the following, plans to improve the usability are covered.
|
|||
|
||||
#### No Output After `cargo check`
|
||||
|
||||
Currently when `cargo clippy` is run after `cargo check`, it does not produce
|
||||
any output. This is especially problematic since `rust-analyzer` is on the rise
|
||||
Currently, when `cargo clippy` is run after `cargo check`, it does not produce
|
||||
any output. This is especially problematic since `rust-analyzer` is on the rise,
|
||||
and it uses `cargo check` for checking code. A fix is already implemented, but
|
||||
it still has to be pushed over the finish line. This also includes the
|
||||
stabilization of the `cargo clippy --fix` command or the support of multi-span
|
||||
|
@ -221,7 +221,7 @@ regarding the user facing issues.
|
|||
|
||||
Rust's roadmap process was established by [RFC 1728] in 2016. Since then every
|
||||
year a roadmap was published, that defined the bigger plans for the coming
|
||||
years. This years roadmap can be found [here][Rust Roadmap 2021].
|
||||
years. This year roadmap can be found [here][Rust Roadmap 2021].
|
||||
|
||||
[RFC 1728]: https://rust-lang.github.io/rfcs/1728-north-star.html
|
||||
|
||||
|
|
|
@ -16,7 +16,7 @@ lints. For non-trivial lints, it often requires nested pattern matching of AST /
|
|||
HIR nodes. For example, testing that an expression is a boolean literal requires
|
||||
the following checks:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
if let ast::ExprKind::Lit(lit) = &expr.node {
|
||||
if let ast::LitKind::Bool(_) = &lit.node {
|
||||
...
|
||||
|
@ -28,7 +28,7 @@ Writing this kind of matching code quickly becomes a complex task and the
|
|||
resulting code is often hard to comprehend. The code below shows a simplified
|
||||
version of the pattern matching required by the `collapsible_if` lint:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
// simplified version of the collapsible_if lint
|
||||
if let ast::ExprKind::If(check, then, None) = &expr.node {
|
||||
if then.stmts.len() == 1 {
|
||||
|
@ -111,7 +111,7 @@ expressions that are boolean literals with value `false`.
|
|||
|
||||
The pattern can then be used to implement lints in the following way:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
...
|
||||
|
||||
impl EarlyLintPass for MyAwesomeLint {
|
||||
|
@ -346,7 +346,7 @@ pattern!{
|
|||
one could get references to the nodes that matched the subpatterns in the
|
||||
following way:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
...
|
||||
fn check_expr(expr: &syntax::ast::Expr) {
|
||||
if let Some(result) = my_pattern(expr) {
|
||||
|
@ -372,7 +372,7 @@ matches arrays that consist of any number of literal expressions. Because those
|
|||
expressions are named `foo`, the result struct contains a `foo` attribute which
|
||||
is a vector of expressions:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
...
|
||||
if let Some(result) = my_pattern_seq(expr) {
|
||||
result.foo // type: Vec<&syntax::ast::Expr>
|
||||
|
@ -394,7 +394,7 @@ In the pattern above, the `bar` name is only defined if the pattern matches a
|
|||
boolean literal. If it matches an integer literal, the name isn't set. To
|
||||
account for this, the result struct's `bar` attribute is an option type:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
...
|
||||
if let Some(result) = my_pattern_alt(expr) {
|
||||
result.bar // type: Option<&bool>
|
||||
|
@ -404,7 +404,7 @@ if let Some(result) = my_pattern_alt(expr) {
|
|||
It's also possible to use a name in multiple alternation branches if they have
|
||||
compatible types:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
pattern!{
|
||||
// matches if expression is a boolean or integer literal
|
||||
my_pattern_mult: Expr =
|
||||
|
@ -519,7 +519,7 @@ The `Alt`, `Seq` and `Opt` structs look like these:
|
|||
> Note: The current implementation can be found
|
||||
> [here](https://github.com/fkohlgrueber/pattern-matching/blob/dfb3bc9fbab69cec7c91e72564a63ebaa2ede638/pattern-match/src/matchers.rs#L35-L60).
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
pub enum Alt<T> {
|
||||
Any,
|
||||
Elmt(Box<T>),
|
||||
|
@ -580,7 +580,7 @@ implementations is the `IsMatch` trait. It defines how to match *PatternTree*
|
|||
nodes against specific syntax tree nodes. A simplified implementation of the
|
||||
`IsMatch` trait is shown below:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
pub trait IsMatch<O> {
|
||||
fn is_match(&self, other: &'o O) -> bool;
|
||||
}
|
||||
|
@ -619,7 +619,7 @@ approach (matching against the coarse pattern first and checking for additional
|
|||
properties later) might be slower than the current practice of checking for
|
||||
structure and additional properties in one pass. For example, the following lint
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
pattern!{
|
||||
pat_if_without_else: Expr =
|
||||
If(
|
||||
|
@ -644,7 +644,7 @@ first matches against the pattern and then checks that the `then` block doesn't
|
|||
start with a comment. Using clippy's current approach, it's possible to check
|
||||
for these conditions earlier:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
fn check_expr(&mut self, cx: &EarlyContext<'_>, expr: &ast::Expr) {
|
||||
if_chain! {
|
||||
if let ast::ExprKind::If(ref check, ref then, None) = expr.node;
|
||||
|
@ -708,7 +708,7 @@ is similar to actual Rust syntax (probably like the `quote!` macro). For
|
|||
example, a pattern that matches `if` expressions that have `false` in their
|
||||
condition could look like this:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
if false {
|
||||
#[*]
|
||||
}
|
||||
|
@ -742,7 +742,7 @@ affects the structure of the resulting AST. `1 + 0 + 0` is parsed as `(1 + 0) +
|
|||
Another example of a problem would be named submatches. Take a look at this
|
||||
pattern:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
fn test() {
|
||||
1 #foo
|
||||
}
|
||||
|
@ -862,7 +862,7 @@ op b` and recommends changing it to `a op= b` requires that both occurrences of
|
|||
`a` are the same. Using `=#...` as syntax for backreferences, the lint could be
|
||||
implemented like this:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
pattern!{
|
||||
assign_op_pattern: Expr =
|
||||
Assign(_#target, Binary(_, =#target, _)
|
||||
|
|
|
@ -17,8 +17,8 @@ $ rustup component add clippy [--toolchain=<name>]
|
|||
|
||||
## From Source
|
||||
|
||||
Take a look at the [Basics] chapter in the Clippy developer guide to find step
|
||||
by step instructions on how to build and install Clippy from source.
|
||||
Take a look at the [Basics] chapter in the Clippy developer guide to find step-by-step
|
||||
instructions on how to build and install Clippy from source.
|
||||
|
||||
[Basics]: development/basics.md#install-from-source
|
||||
[Usage]: usage.md
|
||||
|
|
|
@ -195,7 +195,7 @@ The maximum cognitive complexity a function can have
|
|||
### disallowed-names
|
||||
The list of disallowed names to lint about. NB: `bar` is not here since it has legitimate uses. The value
|
||||
`".."` can be used as part of the list to indicate, that the configured values should be appended to the
|
||||
default configuration of Clippy. By default any configuration will replace the default value.
|
||||
default configuration of Clippy. By default, any configuration will replace the default value.
|
||||
|
||||
**Default Value:** `["foo", "baz", "quux"]` (`Vec<String>`)
|
||||
|
||||
|
@ -205,7 +205,7 @@ default configuration of Clippy. By default any configuration will replace the d
|
|||
### doc-valid-idents
|
||||
The list of words this lint should not consider as identifiers needing ticks. The value
|
||||
`".."` can be used as part of the list to indicate, that the configured values should be appended to the
|
||||
default configuration of Clippy. By default any configuraction will replace the default value. For example:
|
||||
default configuration of Clippy. By default, any configuration will replace the default value. For example:
|
||||
* `doc-valid-idents = ["ClipPy"]` would replace the default list with `["ClipPy"]`.
|
||||
* `doc-valid-idents = ["ClipPy", ".."]` would append `ClipPy` to the default list.
|
||||
|
||||
|
@ -415,7 +415,7 @@ For internal testing only, ignores the current `publish` settings in the Cargo m
|
|||
Enforce the named macros always use the braces specified.
|
||||
|
||||
A `MacroMatcher` can be added like so `{ name = "macro_name", brace = "(" }`. If the macro
|
||||
is could be used with a full path two `MacroMatcher`s have to be added one with the full path
|
||||
could be used with a full path two `MacroMatcher`s have to be added one with the full path
|
||||
`crate_name::macro_name` and one with just the macro name.
|
||||
|
||||
**Default Value:** `[]` (`Vec<crate::nonstandard_macro_braces::MacroMatcher>`)
|
||||
|
@ -449,7 +449,7 @@ Whether to apply the raw pointer heuristic to determine if a type is `Send`.
|
|||
|
||||
### max-suggested-slice-pattern-length
|
||||
When Clippy suggests using a slice pattern, this is the maximum number of elements allowed in
|
||||
the slice pattern that is suggested. If more elements would be necessary, the lint is suppressed.
|
||||
the slice pattern that is suggested. If more elements are necessary, the lint is suppressed.
|
||||
For example, `[_, _, _, e, ..]` is a slice pattern with 4 elements.
|
||||
|
||||
**Default Value:** `3` (`u64`)
|
||||
|
|
|
@ -17,7 +17,7 @@ The different lint groups were defined in the [Clippy 1.0 RFC].
|
|||
The `clippy::correctness` group is the only lint group in Clippy which lints are
|
||||
deny-by-default and abort the compilation when triggered. This is for good
|
||||
reason: If you see a `correctness` lint, it means that your code is outright
|
||||
wrong or useless and you should try to fix it.
|
||||
wrong or useless, and you should try to fix it.
|
||||
|
||||
Lints in this category are carefully picked and should be free of false
|
||||
positives. So just `#[allow]`ing those lints is not recommended.
|
||||
|
@ -41,7 +41,7 @@ simplify your code. It mostly focuses on code that can be written in a shorter
|
|||
and more readable way, while preserving the semantics.
|
||||
|
||||
If you should see a complexity lint, it usually means that you can remove or
|
||||
replace some code and it is recommended to do so. However, if you need the more
|
||||
replace some code, and it is recommended to do so. However, if you need the more
|
||||
complex code for some expressiveness reason, it is recommended to allow
|
||||
complexity lints on a case-by-case basis.
|
||||
|
||||
|
@ -50,9 +50,9 @@ complexity lints on a case-by-case basis.
|
|||
The `clippy::perf` group gives you suggestions on how you can increase the
|
||||
performance of your code. Those lints are mostly about code that the compiler
|
||||
can't trivially optimize, but has to be written in a slightly different way to
|
||||
make the optimizer's job easier.
|
||||
make the optimizer job easier.
|
||||
|
||||
Perf lints are usually easy to apply and it is recommended to do so.
|
||||
Perf lints are usually easy to apply, and it is recommended to do so.
|
||||
|
||||
## Style
|
||||
|
||||
|
@ -91,7 +91,7 @@ and your use case.
|
|||
|
||||
Lints from this group will restrict you in some way. If you enable a restriction
|
||||
lint for your crate it is recommended to also fix code that this lint triggers
|
||||
on. However, those lints are really strict by design and you might want to
|
||||
on. However, those lints are really strict by design, and you might want to
|
||||
`#[allow]` them in some special cases, with a comment justifying that.
|
||||
|
||||
## Cargo
|
||||
|
|
|
@ -19,7 +19,7 @@ cargo clippy
|
|||
### Lint configuration
|
||||
|
||||
The above command will run the default set of lints, which are included in the
|
||||
lint group `clippy::all`. You might want to use even more lints or you might not
|
||||
lint group `clippy::all`. You might want to use even more lints, or you may not
|
||||
agree with every Clippy lint, and for that there are ways to configure lint
|
||||
levels.
|
||||
|
||||
|
@ -98,7 +98,7 @@ other of Clippy's lint groups.
|
|||
You can configure lint levels in source code the same way you can configure
|
||||
`rustc` lints:
|
||||
|
||||
```rust
|
||||
```rust,ignore
|
||||
#![allow(clippy::style)]
|
||||
|
||||
#[warn(clippy::double_neg)]
|
||||
|
|
|
@ -275,13 +275,13 @@ define_Conf! {
|
|||
///
|
||||
/// The list of disallowed names to lint about. NB: `bar` is not here since it has legitimate uses. The value
|
||||
/// `".."` can be used as part of the list to indicate, that the configured values should be appended to the
|
||||
/// default configuration of Clippy. By default any configuration will replace the default value.
|
||||
/// default configuration of Clippy. By default, any configuration will replace the default value.
|
||||
(disallowed_names: Vec<String> = super::DEFAULT_DISALLOWED_NAMES.iter().map(ToString::to_string).collect()),
|
||||
/// Lint: DOC_MARKDOWN.
|
||||
///
|
||||
/// The list of words this lint should not consider as identifiers needing ticks. The value
|
||||
/// `".."` can be used as part of the list to indicate, that the configured values should be appended to the
|
||||
/// default configuration of Clippy. By default any configuraction will replace the default value. For example:
|
||||
/// default configuration of Clippy. By default, any configuration will replace the default value. For example:
|
||||
/// * `doc-valid-idents = ["ClipPy"]` would replace the default list with `["ClipPy"]`.
|
||||
/// * `doc-valid-idents = ["ClipPy", ".."]` would append `ClipPy` to the default list.
|
||||
///
|
||||
|
@ -390,7 +390,7 @@ define_Conf! {
|
|||
/// Enforce the named macros always use the braces specified.
|
||||
///
|
||||
/// A `MacroMatcher` can be added like so `{ name = "macro_name", brace = "(" }`. If the macro
|
||||
/// is could be used with a full path two `MacroMatcher`s have to be added one with the full path
|
||||
/// could be used with a full path two `MacroMatcher`s have to be added one with the full path
|
||||
/// `crate_name::macro_name` and one with just the macro name.
|
||||
(standard_macro_braces: Vec<crate::nonstandard_macro_braces::MacroMatcher> = Vec::new()),
|
||||
/// Lint: MISSING_ENFORCED_IMPORT_RENAMES.
|
||||
|
@ -408,7 +408,7 @@ define_Conf! {
|
|||
/// Lint: INDEX_REFUTABLE_SLICE.
|
||||
///
|
||||
/// When Clippy suggests using a slice pattern, this is the maximum number of elements allowed in
|
||||
/// the slice pattern that is suggested. If more elements would be necessary, the lint is suppressed.
|
||||
/// the slice pattern that is suggested. If more elements are necessary, the lint is suppressed.
|
||||
/// For example, `[_, _, _, e, ..]` is a slice pattern with 4 elements.
|
||||
(max_suggested_slice_pattern_length: u64 = 3),
|
||||
/// Lint: AWAIT_HOLDING_INVALID_TYPE.
|
||||
|
|
|
@ -35,7 +35,7 @@ relicensing are archived on GitHub. We also have saved Wayback Machine copies of
|
|||
|
||||
The usernames of commenters on these issues can be found in relicense_comments.txt
|
||||
|
||||
There are a couple people in relicense_comments.txt who are not found in contributors.txt:
|
||||
There are a few people in relicense_comments.txt who are not found in contributors.txt:
|
||||
|
||||
- @EpocSquadron has [made minor text contributions to the
|
||||
README](https://github.com/rust-lang/rust-clippy/commits?author=EpocSquadron) which have since been overwritten, and
|
||||
|
@ -55,7 +55,7 @@ There are a couple people in relicense_comments.txt who are not found in contrib
|
|||
we rewrote (see below)
|
||||
|
||||
|
||||
Two of these contributors had nonminor contributions (#2184, #427) requiring a rewrite, carried out in #3251
|
||||
Two of these contributors had non-minor contributions (#2184, #427) requiring a rewrite, carried out in #3251
|
||||
([archive](http://web.archive.org/web/20181005192411/https://github.com/rust-lang-nursery/rust-clippy/pull/3251),
|
||||
[screenshot](https://user-images.githubusercontent.com/1617736/46573515-5cb69580-c94b-11e8-86e5-b456452121b2.png))
|
||||
|
||||
|
|
|
@ -16,7 +16,7 @@ or
|
|||
cargo lintcheck
|
||||
```
|
||||
|
||||
By default the logs will be saved into
|
||||
By default, the logs will be saved into
|
||||
`lintcheck-logs/lintcheck_crates_logs.txt`.
|
||||
|
||||
You can set a custom sources.toml by adding `--crates-toml custom.toml` or using
|
||||
|
|
Loading…
Reference in a new issue