OpenE2K
/
rust
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Make the lint docstrings more consistent.

This commit is contained in:
Georg Brandl 2016-08-06 09:55:04 +02:00
parent bc2ecc9623
commit 3b5ff0f813
72 changed files with 914 additions and 677 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
CONTRIBUTING.md
View File

@ -42,13 +42,16 @@ travis build actually checks for this.
Also please document your lint with a doc comment akin to the following:
```rust
/// **What it does:** Describe what the lint matches.
/// **What it does:** Checks for ... (describe what the lint matches).
///
/// **Why is this bad?** Write the reason for linting the code.
/// **Why is this bad?** Supply the reason for linting the code.
///
/// **Known problems:** Hopefully none.
/// **Known problems:** None. (Or describe where it could go wrong.)
///
/// **Example:** Insert a short example if you have one
/// **Example:**
/// ```rust
/// Insert a short example if you have one.
/// ```
```
Our `util/update_wiki.py` script can then add your lint docs to the wiki.

20
clippy_lints/src/approx_const.rs
View File

@ -4,11 +4,22 @@ use std::f64::consts as f64;
use syntax::ast::{Lit, LitKind, FloatTy};
use utils::span_lint;
/// **What it does:** This lint checks for floating point literals that approximate constants which are defined in [`std::f32::consts`](https://doc.rust-lang.org/stable/std/f32/consts/#constants) or [`std::f64::consts`](https://doc.rust-lang.org/stable/std/f64/consts/#constants), respectively, suggesting to use the predefined constant.
/// **What it does:** Checks for floating point literals that approximate
/// constants which are defined in
/// [`std::f32::consts`](https://doc.rust-lang.org/stable/std/f32/consts/#constants)
/// or
/// [`std::f64::consts`](https://doc.rust-lang.org/stable/std/f64/consts/#constants),
/// respectively, suggesting to use the predefined constant.
///
/// **Why is this bad?** Usually, the definition in the standard library is more precise than what people come up with. If you find that your definition is actually more precise, please [file a Rust issue](https://github.com/rust-lang/rust/issues).
/// **Why is this bad?** Usually, the definition in the standard library is more
/// precise than what people come up with. If you find that your definition is
/// actually more precise, please [file a Rust
/// issue](https://github.com/rust-lang/rust/issues).
///
/// **Known problems:** If you happen to have a value that is within 1/8192 of a known constant, but is not *and should not* be the same, this lint will report your value anyway. We have not yet noticed any false positives in code we tested clippy with (this includes servo), but YMMV.
/// **Known problems:** If you happen to have a value that is within 1/8192 of a
/// known constant, but is not *and should not* be the same, this lint will
/// report your value anyway. We have not yet noticed any false positives in
/// code we tested clippy with (this includes servo), but YMMV.
///
/// **Example:**
/// ```rust
@ -72,7 +83,8 @@ fn check_known_consts(cx: &LateContext, e: &Expr, s: &str, module: &str) {
span_lint(cx,
APPROX_CONSTANT,
e.span,
&format!("approximate value of `{}::consts::{}` found. Consider using it directly", module, &name));
&format!("approximate value of `{}::consts::{}` found. \
Consider using it directly", module, &name));
return;
}
}

10
clippy_lints/src/arithmetic.rs
View File

@ -3,13 +3,13 @@ use rustc::lint::*;
use syntax::codemap::Span;
use utils::span_lint;
/// **What it does:** This lint checks for plain integer arithmetic
/// **What it does:** Checks for plain integer arithmetic.
///
/// **Why is this bad?** This is only checked against overflow in debug builds.
/// In some applications one wants explicitly checked, wrapping or saturating
/// arithmetic.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -20,12 +20,12 @@ declare_restriction_lint! {
"Any integer arithmetic statement"
}
/// **What it does:** This lint checks for float arithmetic
/// **What it does:** Checks for float arithmetic.
///
/// **Why is this bad?** For some embedded systems or kernel development, it
/// can be useful to rule out floating-point numbers
/// can be useful to rule out floating-point numbers.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

12
clippy_lints/src/array_indexing.rs
View File

@ -8,14 +8,13 @@ use rustc::hir::*;
use syntax::ast::RangeLimits;
use utils::{self, higher};
/// **What it does:** Check for out of bounds array indexing with a constant index.
/// **What it does:** Checks for out of bounds array indexing with a constant index.
///
/// **Why is this bad?** This will always panic at runtime.
///
/// **Known problems:** Hopefully none.
///
/// **Example:**
///
/// ```rust
/// let x = [1,2,3,4];
/// ...
@ -28,16 +27,15 @@ declare_lint! {
"out of bound constant indexing"
}
/// **What it does:** Check for usage of indexing or slicing.
/// **What it does:** Checks for usage of indexing or slicing.
///
/// **Why is this bad?** Usually, this can be safely allowed. However,
/// in some domains such as kernel development, a panic can cause the
/// whole operating system to crash.
/// **Why is this bad?** Usually, this can be safely allowed. However, in some
/// domains such as kernel development, a panic can cause the whole operating
/// system to crash.
///
/// **Known problems:** Hopefully none.
///
/// **Example:**
///
/// ```rust
/// ...
/// x[2];

20
clippy_lints/src/assign_ops.rs
View File

@ -3,10 +3,10 @@ use rustc::lint::*;
use utils::{span_lint_and_then, snippet_opt, SpanlessEq, get_trait_def_id, implements_trait};
use utils::{higher, sugg};
/// **What it does:** This lint checks for `+=` operations and similar.
/// **What it does:** Checks for compound assignment operations (`+=` and similar).
///
/// **Why is this bad?** Projects with many developers from languages without those operations may
/// find them unreadable and not worth their weight.
/// **Why is this bad?** Projects with many developers from languages without
/// those operations may find them unreadable and not worth their weight.
///
/// **Known problems:** Types implementing `OpAssign` don't necessarily implement `Op`.
///
@ -19,14 +19,14 @@ declare_restriction_lint! {
"any assignment operation"
}
/// **What it does:** Check for `a = a op b` or `a = b commutative_op a` patterns.
/// **What it does:** Checks for `a = a op b` or `a = b commutative_op a` patterns.
///
/// **Why is this bad?** These can be written as the shorter `a op= b`.
///
/// **Known problems:** While forbidden by the spec, `OpAssign` traits may have implementations that differ from the regular `Op` impl.
/// **Known problems:** While forbidden by the spec, `OpAssign` traits may have
/// implementations that differ from the regular `Op` impl.
///
/// **Example:**
///
/// ```rust
/// let mut a = 5;
/// ...
@ -38,14 +38,14 @@ declare_lint! {
"assigning the result of an operation on a variable to that same variable"
}
/// **What it does:** Check for `a op= a op b` or `a op= b op a` patterns.
/// **What it does:** Checks for `a op= a op b` or `a op= b op a` patterns.
///
/// **Why is this bad?** Most likely these are bugs where one meant to write `a op= b`
/// **Why is this bad?** Most likely these are bugs where one meant to write `a op= b`.
///
/// **Known problems:** Someone might actually mean `a op= a op b`, but that should rather be written as `a = (2 * a) op b` where applicable.
/// **Known problems:** Someone might actually mean `a op= a op b`, but that
/// should rather be written as `a = (2 * a) op b` where applicable.
///
/// **Example:**
///
/// ```rust
/// let mut a = 5;
/// ...

23
clippy_lints/src/attrs.rs
View File

@ -9,13 +9,20 @@ use syntax::codemap::Span;
use utils::{in_macro, match_path, span_lint};
use utils::paths;
/// **What it does:** This lint checks for items annotated with `#[inline(always)]`, unless the annotated function is empty or simply panics.
/// **What it does:** Checks for items annotated with `#[inline(always)]`,
/// unless the annotated function is empty or simply panics.
///
/// **Why is this bad?** While there are valid uses of this annotation (and once you know when to use it, by all means `allow` this lint), it's a common newbie-mistake to pepper one's code with it.
/// **Why is this bad?** While there are valid uses of this annotation (and once
/// you know when to use it, by all means `allow` this lint), it's a common
/// newbie-mistake to pepper one's code with it.
///
/// As a rule of thumb, before slapping `#[inline(always)]` on a function, measure if that additional function call really affects your runtime profile sufficiently to make up for the increase in compile time.
/// As a rule of thumb, before slapping `#[inline(always)]` on a function,
/// measure if that additional function call really affects your runtime profile
/// sufficiently to make up for the increase in compile time.
///
/// **Known problems:** False positives, big time. This lint is meant to be deactivated by everyone doing serious performance work. This means having done the measurement.
/// **Known problems:** False positives, big time. This lint is meant to be
/// deactivated by everyone doing serious performance work. This means having
/// done the measurement.
///
/// **Example:**
/// ```rust
@ -27,11 +34,13 @@ declare_lint! {
"`#[inline(always)]` is a bad idea in most cases"
}
/// **What it does:** This lint checks for `#[deprecated]` annotations with a `since` field that is not a valid semantic version..
/// **What it does:** Checks for `#[deprecated]` annotations with a `since`
/// field that is not a valid semantic version.
///
/// **Why is this bad?** For checking the version of the deprecation, it must be valid semver. Failing that, the contained information is useless.
/// **Why is this bad?** For checking the version of the deprecation, it must be
/// a valid semver. Failing that, the contained information is useless.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

57
clippy_lints/src/bit_mask.rs
View File

@ -6,10 +6,12 @@ use syntax::ast::LitKind;
use syntax::codemap::Span;
use utils::span_lint;
/// **What it does:** This lint checks for incompatible bit masks in comparisons.
/// **What it does:** Checks for incompatible bit masks in comparisons.
///
/// The formula for detecting if an expression of the type `_ <bit_op> m <cmp_op> c` (where `<bit_op>`
/// is one of {`&`, `|`} and `<cmp_op>` is one of {`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following table:
/// The formula for detecting if an expression of the type `_ <bit_op> m
/// <cmp_op> c` (where `<bit_op>` is one of {`&`, `|`} and `<cmp_op>` is one of
/// {`!=`, `>=`, `>`, `!=`, `>=`, `>`}) can be determined from the following
/// table:
///
/// |Comparison |Bit Op|Example |is always|Formula |
/// |------------|------|------------|---------|----------------------|
@ -20,11 +22,15 @@ use utils::span_lint;
/// |`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |
/// |`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |
///
/// **Why is this bad?** If the bits that the comparison cares about are always set to zero or one by the bit mask, the comparison is constant `true` or `false` (depending on mask, compared value, and operators).
/// **Why is this bad?** If the bits that the comparison cares about are always
/// set to zero or one by the bit mask, the comparison is constant `true` or
/// `false` (depending on mask, compared value, and operators).
///
/// So the code is actively misleading, and the only reason someone would write this intentionally is to win an underhanded Rust contest or create a test-case for this lint.
/// So the code is actively misleading, and the only reason someone would write
/// this intentionally is to win an underhanded Rust contest or create a
/// test-case for this lint.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -37,16 +43,23 @@ declare_lint! {
(because in the example `select` containing bits that `mask` doesn't have)"
}
/// **What it does:** This lint checks for bit masks in comparisons which can be removed without changing the outcome. The basic structure can be seen in the following table:
/// **What it does:** Checks for bit masks in comparisons which can be removed
/// without changing the outcome. The basic structure can be seen in the
/// following table:
///
/// |Comparison| Bit Op |Example |equals |
/// |----------|---------|-----------|-------|
/// |`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|
/// |`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|
///
/// **Why is this bad?** Not equally evil as [`bad_bit_mask`](#bad_bit_mask), but still a bit misleading, because the bit mask is ineffective.
/// **Why is this bad?** Not equally evil as [`bad_bit_mask`](#bad_bit_mask),
/// but still a bit misleading, because the bit mask is ineffective.
///
/// **Known problems:** False negatives: This lint will only match instances where we have figured out the math (which is for a power-of-two compared value). This means things like `x | 1 >= 7` (which would be better written as `x >= 6`) will not be reported (but bit masks like this are fairly uncommon).
/// **Known problems:** False negatives: This lint will only match instances
/// where we have figured out the math (which is for a power-of-two compared
/// value). This means things like `x | 1 >= 7` (which would be better written
/// as `x >= 6`) will not be reported (but bit masks like this are fairly
/// uncommon).
///
/// **Example:**
/// ```rust
@ -58,32 +71,6 @@ declare_lint! {
"expressions where a bit mask will be rendered useless by a comparison, e.g. `(x | 1) > 2`"
}
/// Checks for incompatible bit masks in comparisons, e.g. `x & 1 == 2`.
/// This cannot work because the bit that makes up the value two was
/// zeroed out by the bit-and with 1. So the formula for detecting if an
/// expression of the type `_ <bit_op> m <cmp_op> c` (where `<bit_op>`
/// is one of {`&`, '|'} and `<cmp_op>` is one of {`!=`, `>=`, `>` ,
/// `!=`, `>=`, `>`}) can be determined from the following table:
///
/// |Comparison |Bit Op|Example |is always|Formula |
/// |------------|------|------------|---------|----------------------|
/// |`==` or `!=`| `&` |`x & 2 == 3`|`false` |`c & m != c` |
/// |`<` or `>=`| `&` |`x & 2 < 3` |`true` |`m < c` |
/// |`>` or `<=`| `&` |`x & 1 > 1` |`false` |`m <= c` |
/// |`==` or `!=`| `|` |`x | 1 == 0`|`false` |`c | m != c` |
/// |`<` or `>=`| `|` |`x | 1 < 1` |`false` |`m >= c` |
/// |`<=` or `>` | `|` |`x | 1 > 0` |`true` |`m > c` |
///
/// This lint is **deny** by default
///
/// There is also a lint that warns on ineffective masks that is *warn*
/// by default.
///
/// |Comparison|Bit Op |Example |equals |Formula|
/// |`>` / `<=`|`|` / `^`|`x | 2 > 3`|`x > 3`|`¹ && m <= c`|
/// |`<` / `>=`|`|` / `^`|`x ^ 1 < 4`|`x < 4`|`¹ && m < c` |
///
/// `¹ power_of_two(c + 1)`
#[derive(Copy,Clone)]
pub struct BitMask;

6
clippy_lints/src/blacklisted_name.rs
View File

@ -2,9 +2,11 @@ use rustc::lint::*;
use rustc::hir::*;
use utils::span_lint;
/// **What it does:** This lints about usage of blacklisted names.
/// **What it does:** Checks for usage of blacklisted names for variables, such
/// as `foo`.
///
/// **Why is this bad?** These names are usually placeholder names and should be avoided.
/// **Why is this bad?** These names are usually placeholder names and should be
/// avoided.
///
/// **Known problems:** None.
///

13
clippy_lints/src/block_in_if_condition.rs
View File

@ -3,11 +3,13 @@ use rustc::hir::*;
use rustc::hir::intravisit::{Visitor, walk_expr};
use utils::*;
/// **What it does:** This lint checks for `if` conditions that use blocks to contain an expression.
/// **What it does:** Checks for `if` conditions that use blocks to contain an
/// expression.
///
/// **Why is this bad?** It isn't really rust style, same as using parentheses to contain expressions.
/// **Why is this bad?** It isn't really Rust style, same as using parentheses
/// to contain expressions.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -18,11 +20,12 @@ declare_lint! {
"braces can be eliminated in conditions that are expressions, e.g `if { true } ...`"
}
/// **What it does:** This lint checks for `if` conditions that use blocks containing statements, or conditions that use closures with blocks.
/// **What it does:** Checks for `if` conditions that use blocks containing
/// statements, or conditions that use closures with blocks.
///
/// **Why is this bad?** Using blocks in the condition makes it hard to read.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

23
clippy_lints/src/booleans.rs
View File

@ -6,25 +6,36 @@ use syntax::codemap::{DUMMY_SP, dummy_spanned};
use syntax::util::ThinVec;
use utils::{span_lint_and_then, in_macro, snippet_opt, SpanlessEq};
/// **What it does:** This lint checks for boolean expressions that can be written more concisely.
/// **What it does:** Checks for boolean expressions that can be written more
/// concisely.
///
/// **Why is this bad?** Readability of boolean expressions suffers from unnecessary duplication.
/// **Why is this bad?** Readability of boolean expressions suffers from
/// unnecessary duplication.
///
/// **Known problems:** Ignores short circuiting behavior of `||` and `&&`. Ignores `|`, `&` and `^`.
/// **Known problems:** Ignores short circuiting behavior of `||` and
/// `&&`. Ignores `|`, `&` and `^`.
///
/// **Example:** `if a && true` should be `if a` and `!(a == b)` should be `a != b`
/// **Example:**
/// ```rust
/// if a && true // should be: if a
/// if !(a == b) // should be: if a != b
declare_lint! {
pub NONMINIMAL_BOOL, Allow,
"checks for boolean expressions that can be written more concisely"
}
/// **What it does:** This lint checks for boolean expressions that contain terminals that can be eliminated.
/// **What it does:** Checks for boolean expressions that contain terminals that
/// can be eliminated.
///
/// **Why is this bad?** This is most likely a logic bug.
///
/// **Known problems:** Ignores short circuiting behavior.
///
/// **Example:** The `b` in `if a && b || a` is unnecessary because the expression is equivalent to `if a`
/// **Example:**
/// ```rust
/// if a && b || a { ... }
/// ```
/// The `b` is unnecessary, the expression is equivalent to `if a`.
declare_lint! {
pub LOGIC_BUG, Warn,
"checks for boolean expressions that contain terminals which can be eliminated"

11
clippy_lints/src/collapsible_if.rs
View File

@ -18,13 +18,14 @@ use syntax::ast;
use utils::{in_macro, snippet_block, span_lint_and_then};
use utils::sugg::Sugg;
/// **What it does:** This lint checks for nested `if`-statements which can be collapsed by
/// `&&`-combining their conditions and for `else { if .. }` expressions that can be collapsed to
/// `else if ..`.
/// **What it does:** Checks for nested `if` statements which can be collapsed
/// by `&&`-combining their conditions and for `else { if ... }` expressions that
/// can be collapsed to `else if ...`.
///
/// **Why is this bad?** Each `if`-statement adds one level of nesting, which makes code look more complex than it really is.
/// **Why is this bad?** Each `if`-statement adds one level of nesting, which
/// makes code look more complex than it really is.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

15
clippy_lints/src/copies.rs
View File

@ -8,7 +8,7 @@ use syntax::util::small_vector::SmallVector;
use utils::{SpanlessEq, SpanlessHash};
use utils::{get_parent_expr, in_macro, span_lint_and_then, span_note_and_lint, snippet};
/// **What it does:** This lint checks for consecutive `ifs` with the same condition.
/// **What it does:** Checks for consecutive `if`s with the same condition.
///
/// **Why is this bad?** This is probably a copy & paste error.
///
@ -23,7 +23,8 @@ use utils::{get_parent_expr, in_macro, span_lint_and_then, span_note_and_lint, s
/// }
/// ```
///
/// Note that this lint ignores all conditions with a function call as it could have side effects:
/// Note that this lint ignores all conditions with a function call as it could
/// have side effects:
///
/// ```rust
/// if foo() {
@ -38,8 +39,8 @@ declare_lint! {
"consecutive `ifs` with the same condition"
}
/// **What it does:** This lint checks for `if/else` with the same body as the *then* part and the
/// *else* part.
/// **What it does:** Checks for `if/else` with the same body as the *then* part
/// and the *else* part.
///
/// **Why is this bad?** This is probably a copy & paste error.
///
@ -59,10 +60,10 @@ declare_lint! {
"if with the same *then* and *else* blocks"
}
/// **What it does:** This lint checks for `match` with identical arm bodies.
/// **What it does:** Checks for `match` with identical arm bodies.
///
/// **Why is this bad?** This is probably a copy & paste error. If arm bodies are the same on
/// purpose, you can factor them
/// **Why is this bad?** This is probably a copy & paste error. If arm bodies
/// are the same on purpose, you can factor them
/// [using `|`](https://doc.rust-lang.org/book/patterns.html#multiple-patterns).
///
/// **Known problems:** False positive possible with order dependent `match`

8
clippy_lints/src/cyclomatic_complexity.rs
View File

@ -11,12 +11,12 @@ use syntax::codemap::Span;
use utils::{in_macro, LimitStack, span_help_and_lint, paths, match_type};
/// **What it does:** This lint checks for methods with high cyclomatic complexity
/// **What it does:** Checks for methods with high cyclomatic complexity.
///
/// **Why is this bad?** Methods of high cyclomatic complexity tend to be badly readable. Also LLVM
/// will usually optimize small methods better.
/// **Why is this bad?** Methods of high cyclomatic complexity tend to be badly
/// readable. Also LLVM will usually optimize small methods better.
///
/// **Known problems:** Sometimes it's hard to find a way to reduce the complexity
/// **Known problems:** Sometimes it's hard to find a way to reduce the complexity.
///
/// **Example:** No. You'll see it when you get the warning.
declare_lint! {

23
clippy_lints/src/derive.rs
View File

@ -8,12 +8,13 @@ use syntax::codemap::Span;
use utils::paths;
use utils::{match_path, span_lint_and_then};
/// **What it does:** This lint warns about deriving `Hash` but implementing `PartialEq`
/// **What it does:** Checks for deriving `Hash` but implementing `PartialEq`
/// explicitly.
///
/// **Why is this bad?** The implementation of these traits must agree (for example for use with
/// `HashMap`) so it’s probably a bad idea to use a default-generated `Hash` implementation with
/// an explicitly defined `PartialEq`. In particular, the following must hold for any type:
/// **Why is this bad?** The implementation of these traits must agree (for
/// example for use with `HashMap`) so it’s probably a bad idea to use a
/// default-generated `Hash` implementation with an explicitly defined
/// `PartialEq`. In particular, the following must hold for any type:
///
/// ```rust
/// k1 == k2 ⇒ hash(k1) == hash(k2)
@ -27,7 +28,7 @@ use utils::{match_path, span_lint_and_then};
/// struct Foo;
///
/// impl PartialEq for Foo {
/// ..
/// ...
/// }
/// ```
declare_lint! {
@ -36,12 +37,14 @@ declare_lint! {
"deriving `Hash` but implementing `PartialEq` explicitly"
}
/// **What it does:** This lint warns about explicit `Clone` implementation for `Copy` types.
/// **What it does:** Checks for explicit `Clone` implementations for `Copy`
/// types.
///
/// **Why is this bad?** To avoid surprising behaviour, these traits should agree and the behaviour
/// of `Copy` cannot be overridden. In almost all situations a `Copy` type should have a `Clone`
/// implementation that does nothing more than copy the object, which is what
/// `#[derive(Copy, Clone)]` gets you.
/// **Why is this bad?** To avoid surprising behaviour, these traits should
/// agree and the behaviour of `Copy` cannot be overridden. In almost all
/// situations a `Copy` type should have a `Clone` implementation that does
/// nothing more than copy the object, which is what `#[derive(Copy, Clone)]`
/// gets you.
///
/// **Known problems:** None.
///

14
clippy_lints/src/doc.rs
View File

@ -3,14 +3,16 @@ use syntax::ast;
use syntax::codemap::{Span, BytePos};
use utils::span_lint;
/// **What it does:** This lint checks for the presence of `_`, `::` or camel-case words outside
/// ticks in documentation.
/// **What it does:** Checks for the presence of `_`, `::` or camel-case words
/// outside ticks in documentation.
///
/// **Why is this bad?** *Rustdoc* supports markdown formatting, `_`, `::` and camel-case probably
/// indicates some code which should be included between ticks. `_` can also be used for empasis in
/// markdown, this lint tries to consider that.
/// **Why is this bad?** *Rustdoc* supports markdown formatting, `_`, `::` and
/// camel-case probably indicates some code which should be included between
/// ticks. `_` can also be used for empasis in markdown, this lint tries to
/// consider that.
///
/// **Known problems:** Lots of bad docs won’t be fixed, what the lint checks for is limited.
/// **Known problems:** Lots of bad docs won’t be fixed, what the lint checks
/// for is limited, and there are still false positives.
///
/// **Examples:**
/// ```rust

10
clippy_lints/src/drop_ref.rs
View File

@ -4,11 +4,15 @@ use rustc::hir::*;
use syntax::codemap::Span;
use utils::{match_def_path, paths, span_note_and_lint};
/// **What it does:** This lint checks for calls to `std::mem::drop` with a reference instead of an owned value.
/// **What it does:** Checks for calls to `std::mem::drop` with a reference
/// instead of an owned value.
///
/// **Why is this bad?** Calling `drop` on a reference will only drop the reference itself, which is a no-op. It will not call the `drop` method (from the `Drop` trait implementation) on the underlying referenced value, which is likely what was intended.
/// **Why is this bad?** Calling `drop` on a reference will only drop the
/// reference itself, which is a no-op. It will not call the `drop` method (from
/// the `Drop` trait implementation) on the underlying referenced value, which
/// is likely what was intended.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

4
clippy_lints/src/entry.rs
View File

@ -5,8 +5,8 @@ use syntax::codemap::Span;
use utils::SpanlessEq;
use utils::{get_item_name, match_type, paths, snippet, span_lint_and_then, walk_ptrs_ty};
/// **What it does:** This lint checks for uses of `contains_key` + `insert` on `HashMap` or
/// `BTreeMap`.
/// **What it does:** Checks for uses of `contains_key` + `insert` on `HashMap`
/// or `BTreeMap`.
///
/// **Why is this bad?** Using `entry` is more efficient.
///

10
clippy_lints/src/enum_clike.rs
View File

@ -6,13 +6,13 @@ use rustc_const_math::*;
use rustc::hir::*;
use utils::span_lint;
/// **What it does:** Lints on C-like enumerations that are `repr(isize/usize)` and have values
/// that don't fit into an `i32`.
/// **What it does:** Checks for C-like enumerations that are
/// `repr(isize/usize)` and have values that don't fit into an `i32`.
///
/// **Why is this bad?** This will truncate the variant value on 32 bit architectures, but works
/// fine on 64 bit.
/// **Why is this bad?** This will truncate the variant value on 32 bit
/// architectures, but works fine on 64 bit.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

8
clippy_lints/src/enum_glob_use.rs
View File

@ -9,11 +9,13 @@ use syntax::ast::NodeId;
use syntax::codemap::Span;
use utils::span_lint;
/// **What it does:** Warns when `use`ing all variants of an enumeration.
/// **What it does:** Checks for `use Enum::*`.
///
/// **Why is this bad?** It is usually better style to use the prefixed name of an enumeration variant, rather than importing variants
/// **Why is this bad?** It is usually better style to use the prefixed name of
/// an enumeration variant, rather than importing variants.
///
/// **Known problems:** Old-style enumerations that prefix the variants are still around
/// **Known problems:** Old-style enumerations that prefix the variants are
/// still around.
///
/// **Example:**
/// ```rust

17
clippy_lints/src/enum_variants.rs
View File

@ -7,13 +7,13 @@ use syntax::parse::token::InternedString;
use utils::{span_help_and_lint, span_lint};
use utils::{camel_case_from, camel_case_until, in_macro};
/// **What it does:** Warns on enumeration variants that are prefixed or suffixed by the same
/// characters.
/// **What it does:** Detects enumeration variants that are prefixed or suffixed
/// by the same characters.
///
/// **Why is this bad?** Enumeration variant names should specify their variant, not repeat the
/// enumeration name.
/// **Why is this bad?** Enumeration variant names should specify their variant,
/// not repeat the enumeration name.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -27,11 +27,12 @@ declare_lint! {
"finds enums where all variants share a prefix/postfix"
}
/// **What it does:** Warns on type names that are prefixed or suffixed by the containing module's name
/// **What it does:** Detects type names that are prefixed or suffixed by the
/// containing module's name.
///
/// **Why is this bad?** It requires the user to type the module name twice
/// **Why is this bad?** It requires the user to type the module name twice.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

14
clippy_lints/src/eq_op.rs
View File

@ -2,16 +2,16 @@ use rustc::hir::*;
use rustc::lint::*;
use utils::{SpanlessEq, span_lint};
/// **What it does:** This lint checks for equal operands to comparison, logical and bitwise,
/// difference and division binary operators (`==`, `>`, etc., `&&`, `||`, `&`, `|`, `^`, `-` and
/// `/`).
/// **What it does:** Checks for equal operands to comparison, logical and
/// bitwise, difference and division binary operators (`==`, `>`, etc., `&&`,
/// `||`, `&`, `|`, `^`, `-` and `/`).
///
/// **Why is this bad?** This is usually just a typo or a copy and paste error.
///
/// **Known problems:** False negatives: We had some false positives regarding calls (notably
/// [racer](https://github.com/phildawes/racer) had one instance of `x.pop() && x.pop()`), so we
/// removed matching any function or method calls. We may introduce a whitelist of known pure
/// functions in the future.
/// **Known problems:** False negatives: We had some false positives regarding
/// calls (notably [racer](https://github.com/phildawes/racer) had one instance
/// of `x.pop() && x.pop()`), so we removed matching any function or method
/// calls. We may introduce a whitelist of known pure functions in the future.
///
/// **Example:**
/// ```rust

11
clippy_lints/src/escape.rs
View File

@ -17,15 +17,16 @@ pub struct Pass {
pub too_large_for_stack: u64,
}
/// **What it does:** This lint checks for usage of `Box<T>` where an unboxed `T` would work fine.
/// **What it does:** Checks for usage of `Box<T>` where an unboxed `T` would
/// work fine.
///
/// **Why is this bad?** This is an unnecessary allocation, and bad for performance. It is only
/// necessary to allocate if you wish to move the box into something.
/// **Why is this bad?** This is an unnecessary allocation, and bad for
/// performance. It is only necessary to allocate if you wish to move the box
/// into something.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
///
/// ```rust
/// fn main() {
/// let x = Box::new(1);

19
clippy_lints/src/eta_reduction.rs
View File

@ -7,17 +7,20 @@ use utils::{snippet_opt, span_lint_and_then, is_adjusted};
pub struct EtaPass;
/// **What it does:** This lint checks for closures which just call another function where the
/// function can be called directly. `unsafe` functions or calls where types get adjusted are
/// ignored.
/// **What it does:** Checks for closures which just call another function where
/// the function can be called directly. `unsafe` functions or calls where types
/// get adjusted are ignored.
///
/// **Why is this bad?** Needlessly creating a closure adds code for no
/// benefit and gives the optimizer more work.
/// **Why is this bad?** Needlessly creating a closure adds code for no benefit
/// and gives the optimizer more work.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `xs.map(|x| foo(x))` where `foo(_)` is a plain function that takes the exact
/// argument type of `x`.
/// **Example:**
/// ```rust
/// xs.map(|x| foo(x))
/// ```
/// where `foo(_)` is a plain function that takes the exact argument type of `x`.
declare_lint! {
pub REDUNDANT_CLOSURE, Warn,
"using redundant closures, i.e. `|a| foo(a)` (which can be written as just `foo`)"

19
clippy_lints/src/format.rs
View File

@ -6,17 +6,22 @@ use syntax::ast::LitKind;
use utils::paths;
use utils::{is_expn_of, match_path, match_type, span_lint, walk_ptrs_ty};
/// **What it does:** This lints about use of `format!("string literal with no argument")` and
/// `format!("{}", foo)` where `foo` is a string.
/// **What it does:** Checks for the use of `format!("string literal with no
/// argument")` and `format!("{}", foo)` where `foo` is a string.
///
/// **Why is this bad?** There is no point of doing that. `format!("too")` can be replaced by
/// `"foo".to_owned()` if you really need a `String`. The even worse `&format!("foo")` is often
/// encountered in the wild. `format!("{}", foo)` can be replaced by `foo.clone()` if `foo: String`
/// or `foo.to_owned()` is `foo: &str`.
/// **Why is this bad?** There is no point of doing that. `format!("too")` can
/// be replaced by `"foo".to_owned()` if you really need a `String`. The even
/// worse `&format!("foo")` is often encountered in the wild. `format!("{}",
/// foo)` can be replaced by `foo.clone()` if `foo: String` or `foo.to_owned()`
/// is `foo: &str`.
///
/// **Known problems:** None.
///
/// **Examples:** `format!("foo")` and `format!("{}", foo)`
/// **Examples:**
/// ```rust
/// format!("foo")
/// format!("{}", foo)
/// ```
declare_lint! {
pub USELESS_FORMAT,
Warn,

10
clippy_lints/src/formatting.rs
View File

@ -4,7 +4,7 @@ use syntax::ast;
use utils::{differing_macro_contexts, in_macro, snippet_opt, span_note_and_lint};
use syntax::ptr::P;
/// **What it does:** This lint looks for use of the non-existent `=*`, `=!` and `=-` operators.
/// **What it does:** Checks for use of the non-existent `=*`, `=!` and `=-` operators.
///
/// **Why is this bad?** This is either a typo of `*=`, `!=` or `-=` or confusing.
///
@ -20,11 +20,11 @@ declare_lint! {
"suspicious formatting of `*=`, `-=` or `!=`"
}
/// **What it does:** This lint checks for formatting of `else if`. It lints if the `else` and `if`
/// are not on the same line or the `else` seems to be missing.
/// **What it does:** Checks for formatting of `else if`. It lints if the `else`
/// and `if` are not on the same line or the `else` seems to be missing.
///
/// **Why is this bad?** This is probably some refactoring remnant, even if the code is correct, it
/// might look confusing.
/// **Why is this bad?** This is probably some refactoring remnant, even if the
/// code is correct, it might look confusing.
///
/// **Known problems:** None.
///

28
clippy_lints/src/functions.rs
View File

@ -7,16 +7,15 @@ use syntax::ast;
use syntax::codemap::Span;
use utils::{span_lint, type_is_unsafe_function};
/// **What it does:** Check for functions with too many parameters.
/// **What it does:** Checks for functions with too many parameters.
///
/// **Why is this bad?** Functions with lots of parameters are considered bad style and reduce
/// readability (“what does the 5th parameter mean?”). Consider grouping some parameters into a
/// new type.
/// **Why is this bad?** Functions with lots of parameters are considered bad
/// style and reduce readability (“what does the 5th parameter mean?”). Consider
/// grouping some parameters into a new type.
///
/// **Known problems:** None.
///
/// **Example:**
///
/// ```rust
/// fn foo(x: u32, y: u32, name: &str, c: Color, w: f32, h: f32, a: f32, b: f32) { .. }
/// ```
@ -26,21 +25,22 @@ declare_lint! {
"functions with too many arguments"
}
/// **What it does:** Check for public functions that dereferences raw pointer arguments but are
/// not marked unsafe.
/// **What it does:** Checks for public functions that dereferences raw pointer
/// arguments but are not marked unsafe.
///
/// **Why is this bad?** The function should probably be marked `unsafe`, since for an arbitrary
/// raw pointer, there is no way of telling for sure if it is valid.
/// **Why is this bad?** The function should probably be marked `unsafe`, since
/// for an arbitrary raw pointer, there is no way of telling for sure if it is
/// valid.
///
/// **Known problems:**
///
/// * It does not check functions recursively so if the pointer is passed to a private non-
/// `unsafe` function which does the dereferencing, the lint won't trigger.
/// * It only checks for arguments whose type are raw pointers, not raw pointers got from an
/// argument in some other way (`fn foo(bar: &[*const u8])` or `some_argument.get_raw_ptr()`).
/// * It does not check functions recursively so if the pointer is passed to a
/// private non-`unsafe` function which does the dereferencing, the lint won't trigger.
/// * It only checks for arguments whose type are raw pointers, not raw pointers
/// got from an argument in some other way (`fn foo(bar: &[*const u8])` or
/// `some_argument.get_raw_ptr()`).
///
/// **Example:**
///
/// ```rust
/// pub fn foo(x: *const u8) { println!("{}", unsafe { *x }); }
/// ```

8
clippy_lints/src/identity_op.rs
View File

@ -5,12 +5,12 @@ use syntax::codemap::Span;
use utils::{span_lint, snippet, in_macro};
use rustc_const_math::ConstInt;
/// **What it does:** This lint checks for identity operations, e.g. `x + 0`.
/// **What it does:** Checks for identity operations, e.g. `x + 0`.
///
/// **Why is this bad?** This code can be removed without changing the meaning. So it just obscures
/// what's going on. Delete it mercilessly.
/// **Why is this bad?** This code can be removed without changing the
/// meaning. So it just obscures what's going on. Delete it mercilessly.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

7
clippy_lints/src/if_not_else.rs
View File

@ -5,11 +5,12 @@ use syntax::ast::*;
use utils::span_help_and_lint;
/// **What it does:** Warns on the use of `!` or `!=` in an if condition with an else branch
/// **What it does:** Checks for usage of `!` or `!=` in an if condition with an
/// else branch.
///
/// **Why is this bad?** Negations reduce the readability of statements
/// **Why is this bad?** Negations reduce the readability of statements.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

10
clippy_lints/src/items_after_statements.rs
View File

@ -4,13 +4,13 @@ use rustc::lint::*;
use syntax::ast::*;
use utils::{in_macro, span_lint};
/// **What it does:** This lints checks for items declared after some statement in a block
/// **What it does:** Checks for items declared after some statement in a block.
///
/// **Why is this bad?** Items live for the entire scope they are declared in. But statements are
/// processed in order. This might cause confusion as it's hard to figure out which item is meant
/// in a statement.
/// **Why is this bad?** Items live for the entire scope they are declared
/// in. But statements are processed in order. This might cause confusion as
/// it's hard to figure out which item is meant in a statement.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

27
clippy_lints/src/len_zero.rs
View File

@ -7,14 +7,15 @@ use syntax::codemap::{Span, Spanned};
use syntax::ptr::P;
use utils::{get_item_name, in_macro, snippet, span_lint, span_lint_and_then, walk_ptrs_ty};
/// **What it does:** This lint checks for getting the length of something via `.len()` just to
/// compare to zero, and suggests using `.is_empty()` where applicable.
/// **What it does:** Checks for getting the length of something via `.len()`
/// just to compare to zero, and suggests using `.is_empty()` where applicable.
///
/// **Why is this bad?** Some structures can answer `.is_empty()` much faster than calculating
/// their length. So it is good to get into the habit of using `.is_empty()`, and having it is
/// cheap. Besides, it makes the intent clearer than a comparison.
/// **Why is this bad?** Some structures can answer `.is_empty()` much faster
/// than calculating their length. So it is good to get into the habit of using
/// `.is_empty()`, and having it is cheap. Besides, it makes the intent clearer
/// than a comparison.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -26,14 +27,16 @@ declare_lint! {
could be used instead"
}
/// **What it does:** This lint checks for items that implement `.len()` but not `.is_empty()`.
/// **What it does:** Checks for items that implement `.len()` but not
/// `.is_empty()`.
///
/// **Why is this bad?** It is good custom to have both methods, because for some data structures,
/// asking about the length will be a costly operation, whereas `.is_empty()` can usually answer in
/// constant time. Also it used to lead to false positives on the [`len_zero`](#len_zero) lint –
/// currently that lint will ignore such entities.
/// **Why is this bad?** It is good custom to have both methods, because for
/// some data structures, asking about the length will be a costly operation,
/// whereas `.is_empty()` can usually answer in constant time. Also it used to
/// lead to false positives on the [`len_zero`](#len_zero) lint – currently that
/// lint will ignore such entities.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

2
clippy_lints/src/let_if_seq.rs
View File

@ -3,7 +3,7 @@ use rustc::hir;
use syntax::codemap;
use utils::{snippet, span_lint_and_then};
/// **What it does:** This lint checks for variable declarations immediately followed by a
/// **What it does:** Checks for variable declarations immediately followed by a
/// conditional affectation.
///
/// **Why is this bad?** This is not idiomatic Rust.

23
clippy_lints/src/lifetimes.rs
View File

@ -7,14 +7,15 @@ use std::collections::{HashSet, HashMap};
use syntax::codemap::Span;
use utils::{in_external_macro, span_lint};
/// **What it does:** This lint checks for lifetime annotations which can be removed by relying on
/// lifetime elision.
/// **What it does:** Checks for lifetime annotations which can be removed by
/// relying on lifetime elision.
///
/// **Why is this bad?** The additional lifetimes make the code look more complicated, while there
/// is nothing out of the ordinary going on. Removing them leads to more readable code.
/// **Why is this bad?** The additional lifetimes make the code look more
/// complicated, while there is nothing out of the ordinary going on. Removing
/// them leads to more readable code.
///
/// **Known problems:** Potential false negatives: we bail out if the function has a `where` clause
/// where lifetimes are mentioned.
/// **Known problems:** Potential false negatives: we bail out if the function
/// has a `where` clause where lifetimes are mentioned.
///
/// **Example:**
/// ```rust
@ -27,12 +28,14 @@ declare_lint! {
would allow omitting them"
}
/// **What it does:** This lint checks for lifetimes in generics that are never used anywhere else.
/// **What it does:** Checks for lifetimes in generics that are never used
/// anywhere else.
///
/// **Why is this bad?** The additional lifetimes make the code look more complicated, while there
/// is nothing out of the ordinary going on. Removing them leads to more readable code.
/// **Why is this bad?** The additional lifetimes make the code look more
/// complicated, while there is nothing out of the ordinary going on. Removing
/// them leads to more readable code.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

110
clippy_lints/src/loops.rs
View File

@ -19,13 +19,13 @@ use utils::{snippet, span_lint, get_parent_expr, match_trait_method, match_type,
walk_ptrs_ty};
use utils::paths;
/// **What it does:** This lint checks for looping over the range of `0..len` of some collection
/// just to get the values by index.
/// **What it does:** Checks for looping over the range of `0..len` of some
/// collection just to get the values by index.
///
/// **Why is this bad?** Just iterating the collection itself makes the intent more clear and is
/// probably faster.
/// **Why is this bad?** Just iterating the collection itself makes the intent
/// more clear and is probably faster.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -39,11 +39,13 @@ declare_lint! {
"for-looping over a range of indices where an iterator over items would do"
}
/// **What it does:** This lint checks for loops on `x.iter()` where `&x` will do, and suggest the latter.
/// **What it does:** Checks for loops on `x.iter()` where `&x` will do, and
/// suggests the latter.
///
/// **Why is this bad?** Readability.
///
/// **Known problems:** False negatives. We currently only warn on some known types.
/// **Known problems:** False negatives. We currently only warn on some known
/// types.
///
/// **Example:**
/// ```rust
@ -56,15 +58,16 @@ declare_lint! {
"for-looping over `_.iter()` or `_.iter_mut()` when `&_` or `&mut _` would do"
}
/// **What it does:** This lint checks for loops on `x.next()`.
/// **What it does:** Checks for loops on `x.next()`.
///
/// **Why is this bad?** `next()` returns either `Some(value)` if there was a value, or `None`
/// otherwise. The insidious thing is that `Option<_>` implements `IntoIterator`, so that possibly
/// one value will be iterated, leading to some hard to find bugs. No one will want to write such
/// code [except to win an Underhanded Rust
/// **Why is this bad?** `next()` returns either `Some(value)` if there was a
/// value, or `None` otherwise. The insidious thing is that `Option<_>`
/// implements `IntoIterator`, so that possibly one value will be iterated,
/// leading to some hard to find bugs. No one will want to write such code
/// [except to win an Underhanded Rust
/// Contest](https://www.reddit.com/r/rust/comments/3hb0wm/underhanded_rust_contest/cu5yuhr).
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -76,11 +79,11 @@ declare_lint! {
"for-looping over `_.next()` which is probably not intended"
}
/// **What it does:** This lint checks for `for` loops over `Option` values.
/// **What it does:** Checks for `for` loops over `Option` values.
///
/// **Why is this bad?** Readability. This is more clearly expressed as an `if let`.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -97,11 +100,11 @@ declare_lint! {
"for-looping over an `Option`, which is more clearly expressed as an `if let`"
}
/// **What it does:** This lint checks for `for` loops over `Result` values.
/// **What it does:** Checks for `for` loops over `Result` values.
///
/// **Why is this bad?** Readability. This is more clearly expressed as an `if let`.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -118,15 +121,14 @@ declare_lint! {
"for-looping over a `Result`, which is more clearly expressed as an `if let`"
}
/// **What it does:** This lint detects `loop + match` combinations that are easier written as a
/// `while let` loop.
/// **What it does:** Detects `loop + match` combinations that are easier
/// written as a `while let` loop.
///
/// **Why is this bad?** The `while let` loop is usually shorter and more readable
/// **Why is this bad?** The `while let` loop is usually shorter and more readable.
///
/// **Known problems:** Sometimes the wrong binding is displayed (#383)
/// **Known problems:** Sometimes the wrong binding is displayed (#383).
///
/// **Example:**
///
/// ```rust
/// loop {
/// let x = match y {
@ -146,12 +148,13 @@ declare_lint! {
"`loop { if let { ... } else break }` can be written as a `while let` loop"
}
/// **What it does:** This lint checks for using `collect()` on an iterator without using the
/// result.
/// **What it does:** Checks for using `collect()` on an iterator without using
/// the result.
///
/// **Why is this bad?** It is more idiomatic to use a `for` loop over the iterator instead.
/// **Why is this bad?** It is more idiomatic to use a `for` loop over the
/// iterator instead.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -164,18 +167,19 @@ declare_lint! {
written as a for loop"
}
/// **What it does:** This lint checks for loops over ranges `x..y` where both `x` and `y` are
/// constant and `x` is greater or equal to `y`, unless the range is reversed or has a negative
/// `.step_by(_)`.
/// **What it does:** Checks for loops over ranges `x..y` where both `x` and `y`
/// are constant and `x` is greater or equal to `y`, unless the range is
/// reversed or has a negative `.step_by(_)`.
///
/// **Why is it bad?** Such loops will either be skipped or loop until wrap-around (in debug code,
/// this may `panic!()`). Both options are probably not intended.
/// **Why is it bad?** Such loops will either be skipped or loop until
/// wrap-around (in debug code, this may `panic!()`). Both options are probably
/// not intended.
///
/// **Known problems:** The lint cannot catch loops over dynamically defined ranges. Doing this
/// would require simulating all possible inputs and code paths through the program, which would be
/// complex and error-prone.
/// **Known problems:** The lint cannot catch loops over dynamically defined
/// ranges. Doing this would require simulating all possible inputs and code
/// paths through the program, which would be complex and error-prone.
///
/// **Examples**:
/// **Example:**
/// ```rust
/// for x in 5..10-5 { .. } // oops, stray `-`
/// ```
@ -185,11 +189,12 @@ declare_lint! {
"Iterating over an empty range, such as `10..0` or `5..5`"
}
/// **What it does:** This lint checks `for` loops over slices with an explicit counter and
/// suggests the use of `.enumerate()`.
/// **What it does:** Checks `for` loops over slices with an explicit counter
/// and suggests the use of `.enumerate()`.
///
/// **Why is it bad?** Not only is the version using `.enumerate()` more readable, the compiler is
/// able to remove bounds checks which can lead to faster code in some instances.
/// **Why is it bad?** Not only is the version using `.enumerate()` more
/// readable, the compiler is able to remove bounds checks which can lead to
/// faster code in some instances.
///
/// **Known problems:** None.
///
@ -204,13 +209,13 @@ declare_lint! {
"for-looping with an explicit counter when `_.enumerate()` would do"
}
/// **What it does:** This lint checks for empty `loop` expressions.
/// **What it does:** Checks for empty `loop` expressions.
///
/// **Why is this bad?** Those busy loops burn CPU cycles without doing anything. Think of the
/// environment and either block on something or at least make the thread sleep for some
/// microseconds.
/// **Why is this bad?** Those busy loops burn CPU cycles without doing
/// anything. Think of the environment and either block on something or at least
/// make the thread sleep for some microseconds.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -222,11 +227,12 @@ declare_lint! {
"empty `loop {}` detected"
}
/// **What it does:** This lint checks for `while let` expressions on iterators.
/// **What it does:** Checks for `while let` expressions on iterators.
///
/// **Why is this bad?** Readability. A simple `for` loop is shorter and conveys the intent better.
/// **Why is this bad?** Readability. A simple `for` loop is shorter and conveys
/// the intent better.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -238,13 +244,13 @@ declare_lint! {
"using a while-let loop instead of a for loop on an iterator"
}
/// **What it does:** This warns when you iterate on a map (`HashMap` or `BTreeMap`) and ignore
/// either the keys or values.
/// **What it does:** Checks for iterating a map (`HashMap` or `BTreeMap`) and
/// ignoring either the keys or values.
///
/// **Why is this bad?** Readability. There are `keys` and `values` methods that can be used to
/// express that don't need the values or keys.
/// **Why is this bad?** Readability. There are `keys` and `values` methods that
/// can be used to express that don't need the values or keys.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

7
clippy_lints/src/map_clone.rs
View File

@ -4,11 +4,12 @@ use syntax::ast;
use utils::{is_adjusted, match_path, match_trait_method, match_type, paths, snippet,
span_help_and_lint, walk_ptrs_ty, walk_ptrs_ty_depth};
/// **What it does:** This lint checks for mapping clone() over an iterator.
/// **What it does:** Checks for mapping `clone()` over an iterator.
///
/// **Why is this bad?** It makes the code less readable.
/// **Why is this bad?** It makes the code less readable than using the
/// `.cloned()` adapter.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

40
clippy_lints/src/matches.rs
View File

@ -12,12 +12,12 @@ use utils::paths;
use utils::{match_type, snippet, span_note_and_lint, span_lint_and_then, in_external_macro, expr_block};
use utils::sugg::Sugg;
/// **What it does:** This lint checks for matches with a single arm where an `if let` will usually
/// suffice.
/// **What it does:** Checks for matches with a single arm where an `if let`
/// will usually suffice.
///
/// **Why is this bad?** Just readability – `if let` nests less than a `match`.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -32,12 +32,12 @@ declare_lint! {
is `_ => {}`) is used; recommends `if let` instead"
}
/// **What it does:** This lint checks for matches with a two arms where an `if let` will usually
/// suffice.
/// **What it does:** Checks for matches with a two arms where an `if let` will
/// usually suffice.
///
/// **Why is this bad?** Just readability – `if let` nests less than a `match`.
///
/// **Known problems:** Personal style preferences may differ
/// **Known problems:** Personal style preferences may differ.
///
/// **Example:**
/// ```rust
@ -52,17 +52,16 @@ declare_lint! {
recommends `if let` instead"
}
/// **What it does:** This lint checks for matches where all arms match a reference, suggesting to
/// remove the reference and deref the matched expression instead. It also checks for `if let &foo
/// = bar` blocks.
/// **What it does:** Checks for matches where all arms match a reference,
/// suggesting to remove the reference and deref the matched expression
/// instead. It also checks for `if let &foo = bar` blocks.
///
/// **Why is this bad?** It just makes the code less readable. That reference destructuring adds
/// nothing to the code.
/// **Why is this bad?** It just makes the code less readable. That reference
/// destructuring adds nothing to the code.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
///
/// ```rust
/// match x {
/// &A(ref y) => foo(y),
@ -76,15 +75,14 @@ declare_lint! {
dereferenced instead"
}
/// **What it does:** This lint checks for matches where match expression is a `bool`. It suggests
/// to replace the expression with an `if...else` block.
/// **What it does:** Checks for matches where match expression is a `bool`. It
/// suggests to replace the expression with an `if...else` block.
///
/// **Why is this bad?** It makes the code less readable.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
///
/// ```rust
/// let condition: bool = true;
/// match condition {
@ -97,14 +95,14 @@ declare_lint! {
"a match on boolean expression; recommends `if..else` block instead"
}
/// **What it does:** This lint checks for overlapping match arms.
/// **What it does:** Checks for overlapping match arms.
///
/// **Why is this bad?** It is likely to be an error and if not, makes the code less obvious.
/// **Why is this bad?** It is likely to be an error and if not, makes the code
/// less obvious.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
///
/// ```rust
/// let x = 5;
/// match x {

6
clippy_lints/src/mem_forget.rs
View File

@ -2,10 +2,10 @@ use rustc::lint::*;
use rustc::hir::{Expr, ExprCall, ExprPath};
use utils::{match_def_path, paths, span_lint};
/// **What it does:** This lint checks for usage of `std::mem::forget(t)` where `t` is `Drop`.
/// **What it does:** Checks for usage of `std::mem::forget(t)` where `t` is `Drop`.
///
/// **Why is this bad?** `std::mem::forget(t)` prevents `t` from running its destructor, possibly
/// causing leaks
/// **Why is this bad?** `std::mem::forget(t)` prevents `t` from running its
/// destructor, possibly causing leaks.
///
/// **Known problems:** None.
///

168
clippy_lints/src/methods.rs
View File

@ -20,13 +20,14 @@ use utils::sugg;
#[derive(Clone)]
pub struct Pass;
/// **What it does:** This lint checks for `.unwrap()` calls on `Option`s.
/// **What it does:** Checks for `.unwrap()` calls on `Option`s.
///
/// **Why is this bad?** Usually it is better to handle the `None` case, or to at least call
/// `.expect(_)` with a more helpful message. Still, for a lot of quick-and-dirty code, `unwrap` is
/// a good choice, which is why this lint is `Allow` by default.
/// **Why is this bad?** Usually it is better to handle the `None` case, or to
/// at least call `.expect(_)` with a more helpful message. Still, for a lot of
/// quick-and-dirty code, `unwrap` is a good choice, which is why this lint is
/// `Allow` by default.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -37,16 +38,17 @@ declare_lint! {
"using `Option.unwrap()`, which should at least get a better message using `expect()`"
}
/// **What it does:** This lint checks for `.unwrap()` calls on `Result`s.
/// **What it does:** Checks for `.unwrap()` calls on `Result`s.
///
/// **Why is this bad?** `result.unwrap()` will let the thread panic on `Err` values. Normally, you
/// want to implement more sophisticated error handling, and propagate errors upwards with `try!`.
/// **Why is this bad?** `result.unwrap()` will let the thread panic on `Err`
/// values. Normally, you want to implement more sophisticated error handling,
/// and propagate errors upwards with `try!`.
///
/// Even if you want to panic on errors, not all `Error`s implement good messages on display.
/// Therefore it may be beneficial to look at the places where they may get displayed. Activate
/// this lint to do just that.
/// Even if you want to panic on errors, not all `Error`s implement good
/// messages on display. Therefore it may be beneficial to look at the places
/// where they may get displayed. Activate this lint to do just that.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -57,15 +59,17 @@ declare_lint! {
"using `Result.unwrap()`, which might be better handled"
}
/// **What it does:** This lint checks for methods that should live in a trait implementation of a
/// `std` trait (see [llogiq's blog post](http://llogiq.github.io/2015/07/30/traits.html) for
/// further information) instead of an inherent implementation.
/// **What it does:** Checks for methods that should live in a trait
/// implementation of a `std` trait (see [llogiq's blog
/// post](http://llogiq.github.io/2015/07/30/traits.html) for further
/// information) instead of an inherent implementation.
///
/// **Why is this bad?** Implementing the traits improve ergonomics for users of the code, often
/// with very little cost. Also people seeing a `mul(..)` method may expect `*` to work equally, so
/// you should have good reason to disappoint them.
/// **Why is this bad?** Implementing the traits improve ergonomics for users of
/// the code, often with very little cost. Also people seeing a `mul(...)` method
/// may expect `*` to work equally, so you should have good reason to disappoint
/// them.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -79,8 +83,8 @@ declare_lint! {
"defining a method that should be implementing a std trait"
}
/// **What it does:** This lint checks for methods with certain name prefixes and which doesn't
/// match how self is taken. The actual rules are:
/// **What it does:** Checks for methods with certain name prefixes and which
/// doesn't match how self is taken. The actual rules are:
///
/// |Prefix |`self` taken |
/// |-------|----------------------|
@ -90,13 +94,13 @@ declare_lint! {
/// |`is_` |`&self` or none |
/// |`to_` |`&self` |
///
/// **Why is this bad?** Consistency breeds readability. If you follow the conventions, your users
/// won't be surprised that they, e.g., need to supply a mutable reference to a `as_..` function.
/// **Why is this bad?** Consistency breeds readability. If you follow the
/// conventions, your users won't be surprised that they, e.g., need to supply a
/// mutable reference to a `as_..` function.
///
/// **Known problems:** None
///
/// **Example**
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
/// impl X {
/// fn as_str(self) -> &str { .. }
@ -108,14 +112,14 @@ declare_lint! {
`self` with the wrong convention"
}
/// **What it does:** This is the same as [`wrong_self_convention`](#wrong_self_convention), but
/// for public items.
/// **What it does:** This is the same as
/// [`wrong_self_convention`](#wrong_self_convention), but for public items.
///
/// **Why is this bad?** See [`wrong_self_convention`](#wrong_self_convention).
///
/// **Known problems:** Actually *renaming* the function may break clients if the function is part
/// of the public interface. In that case, be mindful of the stability guarantees you've given your
/// users.
/// **Known problems:** Actually *renaming* the function may break clients if
/// the function is part of the public interface. In that case, be mindful of
/// the stability guarantees you've given your users.
///
/// **Example:**
/// ```rust
@ -129,10 +133,10 @@ declare_lint! {
`self` with the wrong convention"
}
/// **What it does:** This lint checks for usage of `ok().expect(..)`.
/// **What it does:** Checks for usage of `ok().expect(..)`.
///
/// **Why is this bad?** Because you usually call `expect()` on the `Result` directly to get a good
/// error message.
/// **Why is this bad?** Because you usually call `expect()` on the `Result`
/// directly to get a better error message.
///
/// **Known problems:** None.
///
@ -146,9 +150,10 @@ declare_lint! {
calling `expect` directly on the Result"
}
/// **What it does:** This lint checks for usage of `_.map(_).unwrap_or(_)`.
/// **What it does:** Checks for usage of `_.map(_).unwrap_or(_)`.
///
/// **Why is this bad?** Readability, this can be written more concisely as `_.map_or(_, _)`.
/// **Why is this bad?** Readability, this can be written more concisely as
/// `_.map_or(_, _)`.
///
/// **Known problems:** None.
///
@ -162,9 +167,10 @@ declare_lint! {
`map_or(a, f)`"
}
/// **What it does:** This lint `Warn`s on `_.map(_).unwrap_or_else(_)`.
/// **What it does:** Checks for usage of `_.map(_).unwrap_or_else(_)`.
///
/// **Why is this bad?** Readability, this can be written more concisely as `_.map_or_else(_, _)`.
/// **Why is this bad?** Readability, this can be written more concisely as
/// `_.map_or_else(_, _)`.
///
/// **Known problems:** None.
///
@ -178,9 +184,10 @@ declare_lint! {
`map_or_else(g, f)`"
}
/// **What it does:** This lint `Warn`s on `_.filter(_).next()`.
/// **What it does:** Checks for usage of `_.filter(_).next()`.
///
/// **Why is this bad?** Readability, this can be written more concisely as `_.find(_)`.
/// **Why is this bad?** Readability, this can be written more concisely as
/// `_.find(_)`.
///
/// **Known problems:** None.
///
@ -193,12 +200,14 @@ declare_lint! {
"using `filter(p).next()`, which is more succinctly expressed as `.find(p)`"
}
/// **What it does:** This lint `Warn`s on `_.filter(_).map(_)`, `_.filter(_).flat_map(_)`,
/// `_.filter_map(_).flat_map(_)` and similar.
/// **What it does:** Checks for usage of `_.filter(_).map(_)`,
/// `_.filter(_).flat_map(_)`, `_.filter_map(_).flat_map(_)` and similar.
///
/// **Why is this bad?** Readability, this can be written more concisely as a single method call
/// **Why is this bad?** Readability, this can be written more concisely as a
/// single method call.
///
/// **Known problems:** Often requires a condition + Option/Iterator creation inside the closure
/// **Known problems:** Often requires a condition + Option/Iterator creation
/// inside the closure.
///
/// **Example:**
/// ```rust
@ -209,10 +218,11 @@ declare_lint! {
"using combinations of `filter`, `map`, `filter_map` and `flat_map` which can usually be written as a single method call"
}
/// **What it does:** This lint `Warn`s on an iterator search (such as `find()`, `position()`, or
/// `rposition()`) followed by a call to `is_some()`.
/// **What it does:** Checks for an iterator search (such as `find()`,
/// `position()`, or `rposition()`) followed by a call to `is_some()`.
///
/// **Why is this bad?** Readability, this can be written more concisely as `_.any(_)`.
/// **Why is this bad?** Readability, this can be written more concisely as
/// `_.any(_)`.
///
/// **Known problems:** None.
///
@ -226,10 +236,11 @@ declare_lint! {
expressed as a call to `any()`"
}
/// **What it does:** This lint `Warn`s on using `.chars().next()` on a `str` to check if it
/// starts with a given char.
/// **What it does:** Checks for usage of `.chars().next()` on a `str` to check
/// if it starts with a given char.
///
/// **Why is this bad?** Readability, this can be written more concisely as `_.starts_with(_)`.
/// **Why is this bad?** Readability, this can be written more concisely as
/// `_.starts_with(_)`.
///
/// **Known problems:** None.
///
@ -242,11 +253,17 @@ declare_lint! {
"using `.chars().next()` to check if a string starts with a char"
}
/// **What it does:** This lint checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`, etc., and
/// suggests to use `or_else`, `unwrap_or_else`, etc., or `unwrap_or_default` instead.
/// **What it does:** Checks for calls to `.or(foo(..))`, `.unwrap_or(foo(..))`,
/// etc., and suggests to use `or_else`, `unwrap_or_else`, etc., or
/// `unwrap_or_default` instead.
///
/// **Why is this bad?** The function will always be called and potentially allocate an object
/// in expressions such as:
/// **Why is this bad?** The function will always be called and potentially
/// allocate an object acting as the default.
///
/// **Known problems:** If the function has side-effects, not calling it will
/// change the semantic of the program, but you shouldn't rely on that anyway.
///
/// **Example:**
/// ```rust
/// foo.unwrap_or(String::new())
/// ```
@ -258,17 +275,16 @@ declare_lint! {
/// ```rust
/// foo.unwrap_or_default()
/// ```
///
/// **Known problems:** If the function as side-effects, not calling it will change the semantic of
/// the program, but you shouldn't rely on that anyway.
declare_lint! {
pub OR_FUN_CALL, Warn,
"using any `*or` method when the `*or_else` would do"
}
/// **What it does:** This lint checks for usage of `.extend(s)` on a `Vec` to extend the vector by a slice.
/// **What it does:** Checks for usage of `.extend(s)` on a `Vec` to extend the
/// vector by a slice.
///
/// **Why is this bad?** Since Rust 1.6, the `extend_from_slice(_)` method is stable and at least for now faster.
/// **Why is this bad?** Since Rust 1.6, the `extend_from_slice(_)` method is
/// stable and at least for now faster.
///
/// **Known problems:** None.
///
@ -281,10 +297,10 @@ declare_lint! {
"`.extend_from_slice(_)` is a faster way to extend a Vec by a slice"
}
/// **What it does:** This lint warns on using `.clone()` on a `Copy` type.
/// **What it does:** Checks for usage of `.clone()` on a `Copy` type.
///
/// **Why is this bad?** The only reason `Copy` types implement `Clone` is for generics, not for
/// using the `clone` method on a concrete type.
/// **Why is this bad?** The only reason `Copy` types implement `Clone` is for
/// generics, not for using the `clone` method on a concrete type.
///
/// **Known problems:** None.
///
@ -296,10 +312,10 @@ declare_lint! {
pub CLONE_ON_COPY, Warn, "using `clone` on a `Copy` type"
}
/// **What it does:** This lint warns on using `.clone()` on an `&&T`
/// **What it does:** Checks for usage of `.clone()` on an `&&T`.
///
/// **Why is this bad?** Cloning an `&&T` copies the inner `&T`, instead of cloning the underlying
/// `T`
/// **Why is this bad?** Cloning an `&&T` copies the inner `&T`, instead of
/// cloning the underlying `T`.
///
/// **Known problems:** None.
///
@ -316,9 +332,10 @@ declare_lint! {
pub CLONE_DOUBLE_REF, Warn, "using `clone` on `&&T`"
}
/// **What it does:** This lint warns about `new` not returning `Self`.
/// **What it does:** Checks for `new` not returning `Self`.
///
/// **Why is this bad?** As a convention, `new` methods are used to make a new instance of a type.
/// **Why is this bad?** As a convention, `new` methods are used to make a new
/// instance of a type.
///
/// **Known problems:** None.
///
@ -333,9 +350,11 @@ declare_lint! {
pub NEW_RET_NO_SELF, Warn, "not returning `Self` in a `new` method"
}
/// **What it does:** This lint checks for string methods that receive a single-character `str` as an argument, e.g. `_.split("x")`.
/// **What it does:** Checks for string methods that receive a single-character
/// `str` as an argument, e.g. `_.split("x")`.
///
/// **Why is this bad?** Performing these methods using a `char` is faster than using a `str`.
/// **Why is this bad?** Performing these methods using a `char` is faster than
/// using a `str`.
///
/// **Known problems:** Does not catch multi-byte unicode characters.
///
@ -350,10 +369,10 @@ declare_lint! {
`_.split(\"x\")`"
}
/// **What it does:** This lint checks for getting the inner pointer of a temporary `CString`.
/// **What it does:** Checks for getting the inner pointer of a temporary `CString`.
///
/// **Why is this bad?** The inner pointer of a `CString` is only valid as long as the `CString` is
/// alive.
/// **Why is this bad?** The inner pointer of a `CString` is only valid as long
/// as the `CString` is alive.
///
/// **Known problems:** None.
///
@ -377,10 +396,11 @@ declare_lint! {
"getting the inner pointer of a temporary `CString`"
}
/// **What it does:** This lint checks for use of `.iter().nth()` (and the related
/// **What it does:** Checks for use of `.iter().nth()` (and the related
/// `.iter_mut().nth()`) on standard library types with O(1) element access.
///
/// **Why is this bad?** `.get()` and `.get_mut()` are more efficient and more readable.
/// **Why is this bad?** `.get()` and `.get_mut()` are more efficient and more
/// readable.
///
/// **Known problems:** None.
///

16
clippy_lints/src/minmax.rs
View File

@ -5,16 +5,20 @@ use std::cmp::{PartialOrd, Ordering};
use syntax::ptr::P;
use utils::{match_def_path, paths, span_lint};
/// **What it does:** This lint checks for expressions where `std::cmp::min` and `max` are used to
/// clamp values, but switched so that the result is constant.
/// **What it does:** Checks for expressions where `std::cmp::min` and `max` are
/// used to clamp values, but switched so that the result is constant.
///
/// **Why is this bad?** This is in all probability not the intended outcome. At the least it hurts
/// readability of the code.
/// **Why is this bad?** This is in all probability not the intended outcome. At
/// the least it hurts readability of the code.
///
/// **Known problems:** None
///
/// **Example:** `min(0, max(100, x))` will always be equal to `0`. Probably the author meant to
/// clamp the value between 0 and 100, but has erroneously swapped `min` and `max`.
/// **Example:**
/// ```rust
/// min(0, max(100, x))
/// ```
/// It will always be equal to `0`. Probably the author meant to clamp the value
/// between 0 and 100, but has erroneously swapped `min` and `max`.
declare_lint! {
pub MIN_MAX, Warn,
"`min(_, max(_, _))` (or vice versa) with bounds clamping the result to a constant"

97
clippy_lints/src/misc.rs
View File

@ -15,19 +15,20 @@ use utils::{
};
use utils::sugg::Sugg;
/// **What it does:** This lint checks for function arguments and let bindings denoted as `ref`.
/// **What it does:** Checks for function arguments and let bindings denoted as `ref`.
///
/// **Why is this bad?** The `ref` declaration makes the function take an owned value, but turns
/// the argument into a reference (which means that the value is destroyed when exiting the
/// function). This adds not much value: either take a reference type, or take an owned value and
/// create references in the body.
/// **Why is this bad?** The `ref` declaration makes the function take an owned
/// value, but turns the argument into a reference (which means that the value
/// is destroyed when exiting the function). This adds not much value: either
/// take a reference type, or take an owned value and create references in the
/// body.
///
/// For let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The type of `x` is more
/// obvious with the former.
/// For let bindings, `let x = &foo;` is preferred over `let ref x = foo`. The
/// type of `x` is more obvious with the former.
///
/// **Known problems:** If the argument is dereferenced within the function, removing the `ref`
/// will lead to errors. This can be fixed by removing the dereferences, e.g. changing `*x` to `x`
/// within the function.
/// **Known problems:** If the argument is dereferenced within the function,
/// removing the `ref` will lead to errors. This can be fixed by removing the
/// dereferences, e.g. changing `*x` to `x` within the function.
///
/// **Example:**
/// ```rust
@ -99,13 +100,17 @@ impl LateLintPass for TopLevelRefPass {
}
}
/// **What it does:** This lint checks for comparisons to NAN.
/// **What it does:** Checks for comparisons to NaN.
///
/// **Why is this bad?** NAN does not compare meaningfully to anything – not even itself – so those comparisons are simply wrong.
/// **Why is this bad?** NaN does not compare meaningfully to anything – not
/// even itself – so those comparisons are simply wrong.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `x == NAN`
/// **Example:**
/// ```rust
/// x == NAN
/// ```
declare_lint!(pub CMP_NAN, Deny,
"comparisons to NAN (which will always return false, which is probably not intended)");
@ -144,13 +149,22 @@ fn check_nan(cx: &LateContext, path: &Path, span: Span) {
});
}
/// **What it does:** This lint checks for (in-)equality comparisons on floating-point values (apart from zero), except in functions called `*eq*` (which probably implement equality for a type involving floats).
/// **What it does:** Checks for (in-)equality comparisons on floating-point
/// values (apart from zero), except in functions called `*eq*` (which probably
/// implement equality for a type involving floats).
///
/// **Why is this bad?** Floating point calculations are usually imprecise, so asking if two values are *exactly* equal is asking for trouble. For a good guide on what to do, see [the floating point guide](http://www.floating-point-gui.de/errors/comparison).
/// **Why is this bad?** Floating point calculations are usually imprecise, so
/// asking if two values are *exactly* equal is asking for trouble. For a good
/// guide on what to do, see [the floating point
/// guide](http://www.floating-point-gui.de/errors/comparison).
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `y == 1.23f64`
/// **Example:**
/// ```rust
/// y == 1.23f64
/// y != x // where both are floats
/// ```
declare_lint!(pub FLOAT_CMP, Warn,
"using `==` or `!=` on float values (as floating-point operations \
usually involve rounding errors, it is always better to check for approximate \
@ -230,13 +244,19 @@ fn is_float(cx: &LateContext, expr: &Expr) -> bool {
matches!(walk_ptrs_ty(cx.tcx.expr_ty(expr)).sty, ty::TyFloat(_))
}
/// **What it does:** This lint checks for conversions to owned values just for the sake of a comparison.
/// **What it does:** Checks for conversions to owned values just for the sake
/// of a comparison.
///
/// **Why is this bad?** The comparison can operate on a reference, so creating an owned value effectively throws it away directly afterwards, which is needlessly consuming code and heap space.
/// **Why is this bad?** The comparison can operate on a reference, so creating
/// an owned value effectively throws it away directly afterwards, which is
/// needlessly consuming code and heap space.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `x.to_owned() == y`
/// **Example:**
/// ```rust
/// x.to_owned() == y
/// ```
declare_lint!(pub CMP_OWNED, Warn,
"creating owned instances for comparing with others, e.g. `x == \"foo\".to_string()`");
@ -320,13 +340,19 @@ fn is_str_arg(cx: &LateContext, args: &[P<Expr>]) -> bool {
matches!(walk_ptrs_ty(cx.tcx.expr_ty(&args[0])).sty, ty::TyStr)
}
/// **What it does:** This lint checks for getting the remainder of a division by one.
/// **What it does:** Checks for getting the remainder of a division by one.
///
/// **Why is this bad?** The result can only ever be zero. No one will write such code deliberately, unless trying to win an Underhanded Rust Contest. Even for that contest, it's probably a bad idea. Use something more underhanded.
/// **Why is this bad?** The result can only ever be zero. No one will write
/// such code deliberately, unless trying to win an Underhanded Rust
/// Contest. Even for that contest, it's probably a bad idea. Use something more
/// underhanded.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `x % 1`
/// **Example:**
/// ```rust
/// x % 1
/// ```
declare_lint!(pub MODULO_ONE, Warn, "taking a number modulo 1, which always returns 0");
#[derive(Copy,Clone)]
@ -350,13 +376,13 @@ impl LateLintPass for ModuloOne {
}
}
/// **What it does:** This lint checks for patterns in the form `name @ _`.
/// **What it does:** Checks for patterns in the form `name @ _`.
///
/// **Why is this bad?** It's almost always more readable to just use direct bindings.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example**:
/// **Example:**
/// ```rust
/// match v {
/// Some(x) => (),
@ -390,15 +416,16 @@ impl LateLintPass for PatternPass {
}
/// **What it does:** This lint checks for the use of bindings with a single leading underscore
/// **What it does:** Checks for the use of bindings with a single leading underscore.
///
/// **Why is this bad?** A single leading underscore is usually used to indicate that a binding
/// will not be used. Using such a binding breaks this expectation.
/// **Why is this bad?** A single leading underscore is usually used to indicate
/// that a binding will not be used. Using such a binding breaks this
/// expectation.
///
/// **Known problems:** The lint does not work properly with desugaring and macro, it has been
/// allowed in the mean time.
/// **Known problems:** The lint does not work properly with desugaring and
/// macro, it has been allowed in the mean time.
///
/// **Example**:
/// **Example:**
/// ```rust
/// let _x = 0;
/// let y = _x + 1; // Here we are using `_x`, even though it has a leading underscore.

18
clippy_lints/src/misc_early.rs
View File

@ -5,9 +5,11 @@ use syntax::ast::*;
use syntax::codemap::Span;
use syntax::visit::FnKind;
use utils::{span_lint, span_help_and_lint, snippet, snippet_opt, span_lint_and_then};
/// **What it does:** This lint checks for structure field patterns bound to wildcards.
/// **What it does:** Checks for structure field patterns bound to wildcards.
///
/// **Why is this bad?** Using `..` instead is shorter and leaves the focus on the fields that are actually bound.
/// **Why is this bad?** Using `..` instead is shorter and leaves the focus on
/// the fields that are actually bound.
///
/// **Known problems:** None.
///
@ -20,9 +22,10 @@ declare_lint! {
"Struct fields are bound to a wildcard instead of using `..`"
}
/// **What it does:** This lint checks for function arguments having the similar names differing by an underscore
/// **What it does:** Checks for function arguments having the similar names
/// differing by an underscore.
///
/// **Why is this bad?** It affects code readability
/// **Why is this bad?** It affects code readability.
///
/// **Known problems:** None.
///
@ -35,7 +38,7 @@ declare_lint! {
"Function arguments having names which only differ by an underscore"
}
/// **What it does:** This lint detects closures called in the same expression where they are defined.
/// **What it does:** Detects closures called in the same expression where they are defined.
///
/// **Why is this bad?** It is unnecessarily adding to the expression's complexity.
///
@ -50,9 +53,10 @@ declare_lint! {
"Closures should not be called in the expression they are defined"
}
/// **What it does:** This lint detects expressions of the form `--x`
/// **What it does:** Detects expressions of the form `--x`.
///
/// **Why is this bad?** It can mislead C/C++ programmers to think `x` was decremented.
/// **Why is this bad?** It can mislead C/C++ programmers to think `x` was
/// decremented.
///
/// **Known problems:** None.
///

9
clippy_lints/src/mut_mut.rs
View File

@ -4,12 +4,13 @@ use rustc::lint::*;
use rustc::ty::{TypeAndMut, TyRef};
use utils::{higher, in_external_macro, span_lint};
/// **What it does:** This lint checks for instances of `mut mut` references.
/// **What it does:** Checks for instances of `mut mut` references.
///
/// **Why is this bad?** Multiple `mut`s don't add anything meaningful to the source. This is
/// either a copy'n'paste error, or it shows a fundamental misunderstanding of references)
/// **Why is this bad?** Multiple `mut`s don't add anything meaningful to the
/// source. This is either a copy'n'paste error, or it shows a fundamental
/// misunderstanding of references.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

12
clippy_lints/src/mut_reference.rs
View File

@ -4,15 +4,15 @@ use rustc::hir::*;
use syntax::ptr::P;
use utils::span_lint;
/// **What it does:** This lint detects giving a mutable reference to a function that only requires
/// an immutable reference.
/// **What it does:** Detects giving a mutable reference to a function that only
/// requires an immutable reference.
///
/// **Why is this bad?** The immutable reference rules out all other references to the value. Also
/// the code misleads about the intent of the call site.
/// **Why is this bad?** The immutable reference rules out all other references
/// to the value. Also the code misleads about the intent of the call site.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example**
/// **Example:**
/// ```rust
/// my_vec.push(&mut value)
/// ```

17
clippy_lints/src/mutex_atomic.rs
View File

@ -9,13 +9,15 @@ use rustc::hir::Expr;
use syntax::ast;
use utils::{match_type, paths, span_lint};
/// **What it does:** This lint checks for usages of `Mutex<X>` where an atomic will do.
/// **What it does:** Checks for usages of `Mutex<X>` where an atomic will do.
///
/// **Why is this bad?** Using a mutex just to make access to a plain bool or reference sequential
/// is shooting flies with cannons. `std::atomic::AtomicBool` and `std::atomic::AtomicPtr` are
/// leaner and faster.
/// **Why is this bad?** Using a mutex just to make access to a plain bool or
/// reference sequential is shooting flies with cannons.
/// `std::atomic::AtomicBool` and `std::atomic::AtomicPtr` are leaner and
/// faster.
///
/// **Known problems:** This lint cannot detect if the mutex is actually used for waiting before a critical section.
/// **Known problems:** This lint cannot detect if the mutex is actually used
/// for waiting before a critical section.
///
/// **Example:**
/// ```rust
@ -27,12 +29,13 @@ declare_lint! {
"using a mutex where an atomic value could be used instead"
}
/// **What it does:** This lint checks for usages of `Mutex<X>` where `X` is an integral type.
/// **What it does:** Checks for usages of `Mutex<X>` where `X` is an integral type.
///
/// **Why is this bad?** Using a mutex just to make access to a plain integer sequential is
/// shooting flies with cannons. `std::atomic::usize` is leaner and faster.
///
/// **Known problems:** This lint cannot detect if the mutex is actually used for waiting before a critical section.
/// **Known problems:** This lint cannot detect if the mutex is actually used
/// for waiting before a critical section.
///
/// **Example:**
/// ```rust

18
clippy_lints/src/needless_bool.rs
View File

@ -9,14 +9,15 @@ use syntax::codemap::Spanned;
use utils::{span_lint, span_lint_and_then, snippet};
use utils::sugg::Sugg;
/// **What it does:** This lint checks for expressions of the form `if c { true } else { false }`
/// **What it does:** Checks for expressions of the form `if c { true } else { false }`
/// (or vice versa) and suggest using the condition directly.
///
/// **Why is this bad?** Redundant code.
///
/// **Known problems:** Maybe false positives: Sometimes, the two branches are painstakingly
/// documented (which we of course do not detect), so they *may* have some value. Even then, the
/// documentation can be rewritten to match the shorter code.
/// **Known problems:** Maybe false positives: Sometimes, the two branches are
/// painstakingly documented (which we of course do not detect), so they *may*
/// have some value. Even then, the documentation can be rewritten to match the
/// shorter code.
///
/// **Example:**
/// ```rust
@ -29,14 +30,17 @@ declare_lint! {
`if p { true } else { false }`"
}
/// **What it does:** This lint checks for expressions of the form `x == true` (or vice versa) and
/// suggest using the variable directly.
/// **What it does:** Checks for expressions of the form `x == true` (or vice
/// versa) and suggest using the variable directly.
///
/// **Why is this bad?** Unnecessary code.
///
/// **Known problems:** None.
///
/// **Example:** `if x == true { }` could be `if x { }`
/// **Example:**
/// ```rust
/// if x == true { } // could be `if x { }`
/// ```
declare_lint! {
pub BOOL_COMPARISON,
Warn,

9
clippy_lints/src/needless_borrow.rs
View File

@ -8,12 +8,13 @@ use rustc::ty::TyRef;
use utils::{span_lint, in_macro};
use rustc::ty::adjustment::AutoAdjustment::AdjustDerefRef;
/// **What it does:** This lint checks for address of operations (`&`) that are going to be
/// dereferenced immediately by the compiler
/// **What it does:** Checks for address of operations (`&`) that are going to
/// be dereferenced immediately by the compiler.
///
/// **Why is this bad?** Suggests that the receiver of the expression borrows the expression.
/// **Why is this bad?** Suggests that the receiver of the expression borrows
/// the expression.
///
/// **Known problems:**
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

6
clippy_lints/src/needless_update.rs
View File

@ -3,9 +3,11 @@ use rustc::ty::TyStruct;
use rustc::hir::{Expr, ExprStruct};
use utils::span_lint;
/// **What it does:** This lint warns on needlessly including a base struct on update when all fields are changed anyway.
/// **What it does:** Checks for needlessly including a base struct on update
/// when all fields are changed anyway.
///
/// **Why is this bad?** This will cost resources (because the base has to be somewhere), and make the code less readable.
/// **Why is this bad?** This will cost resources (because the base has to be
/// somewhere), and make the code less readable.
///
/// **Known problems:** None.
///

2
clippy_lints/src/neg_multiply.rs
View File

@ -9,7 +9,7 @@ use utils::span_lint;
///
/// **Why is this bad?** It's more readable to just negate.
///
/// **Known problems:** This only catches integers (for now)
/// **Known problems:** This only catches integers (for now).
///
/// **Example:**
/// ```rust

28
clippy_lints/src/new_without_default.rs
View File

@ -9,13 +9,13 @@ use utils::paths;
use utils::{get_trait_def_id, implements_trait, in_external_macro, return_ty, same_tys, span_lint_and_then};
use utils::sugg::DiagnosticBuilderExt;
/// **What it does:** This lints about type with a `fn new() -> Self` method
/// and no implementation of
/// [`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)
/// **What it does:** Checks for types with a `fn new() -> Self` method and no
/// implementation of
/// [`Default`](https://doc.rust-lang.org/std/default/trait.Default.html).
///
/// **Why is this bad?** User might expect to be able to use
/// [`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)
/// as the type can be constructed without arguments.
/// **Why is this bad?** The user might expect to be able to use
/// [`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the
/// type can be constructed without arguments.
///
/// **Known problems:** Hopefully none.
///
@ -43,21 +43,21 @@ use utils::sugg::DiagnosticBuilderExt;
/// }
/// ```
///
/// You can also have `new()` call `Default::default()`
/// You can also have `new()` call `Default::default()`.
declare_lint! {
pub NEW_WITHOUT_DEFAULT,
Warn,
"`fn new() -> Self` method without `Default` implementation"
}
/// **What it does:** This lints about type with a `fn new() -> Self` method
/// **What it does:** Checks for types with a `fn new() -> Self` method
/// and no implementation of
/// [`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)
/// [`Default`](https://doc.rust-lang.org/std/default/trait.Default.html),
/// where the `Default` can be derived by `#[derive(Default)]`.
///
/// **Why is this bad?** User might expect to be able to use
/// [`Default`](https://doc.rust-lang.org/std/default/trait.Default.html)
/// as the type can be
/// constructed without arguments.
/// **Why is this bad?** The user might expect to be able to use
/// [`Default`](https://doc.rust-lang.org/std/default/trait.Default.html) as the
/// type can be constructed without arguments.
///
/// **Known problems:** Hopefully none.
///
@ -73,7 +73,7 @@ declare_lint! {
/// }
/// ```
///
/// Just prepend `#[derive(Default)]` before the `struct` definition
/// Just prepend `#[derive(Default)]` before the `struct` definition.
declare_lint! {
pub NEW_WITHOUT_DEFAULT_DERIVE,
Warn,

14
clippy_lints/src/no_effect.rs
View File

@ -4,10 +4,11 @@ use rustc::hir::{Expr, Expr_, Stmt, StmtSemi, BlockCheckMode, UnsafeSource};
use utils::{in_macro, span_lint, snippet_opt, span_lint_and_then};
use std::ops::Deref;
/// **What it does:** This lint checks for statements which have no effect.
/// **What it does:** Checks for statements which have no effect.
///
/// **Why is this bad?** Similar to dead code, these statements are actually executed. However, as
/// they have no effect, all they do is make the code less readable.
/// **Why is this bad?** Similar to dead code, these statements are actually
/// executed. However, as they have no effect, all they do is make the code less
/// readable.
///
/// **Known problems:** None.
///
@ -21,10 +22,11 @@ declare_lint! {
"statements with no effect"
}
/// **What it does:** This lint checks for expression statements that can be reduced to a sub-expression
/// **What it does:** Checks for expression statements that can be reduced to a
/// sub-expression.
///
/// **Why is this bad?** Expressions by themselves often have no side-effects. Having such
/// expressions reduces readability.
/// **Why is this bad?** Expressions by themselves often have no side-effects.
/// Having such expressions reduces readability.
///
/// **Known problems:** None.
///

18
clippy_lints/src/non_expressive_names.rs
View File

@ -6,27 +6,33 @@ use syntax::attr;
use syntax::visit::{Visitor, walk_block, walk_pat, walk_expr};
use utils::{span_lint_and_then, in_macro, span_lint};
/// **What it does:** This lint warns about names that are very similar and thus confusing
/// **What it does:** Checks for names that are very similar and thus confusing.
///
/// **Why is this bad?** It's hard to distinguish between names that differ only by a single character
/// **Why is this bad?** It's hard to distinguish between names that differ only
/// by a single character.
///
/// **Known problems:** None?
///
/// **Example:** `checked_exp` and `checked_expr`
/// **Example:**
/// ```rust
/// let checked_exp = something;
/// let checked_expr = something_else;
/// ```
declare_lint! {
pub SIMILAR_NAMES,
Allow,
"similarly named items and bindings"
}
/// **What it does:** This lint warns about having too many variables whose name consists of a single character
/// **What it does:** Checks for too many variables whose name consists of a
/// single character.
///
/// **Why is this bad?** It's hard to memorize what a variable means without a descriptive name.
/// **Why is this bad?** It's hard to memorize what a variable means without a
/// descriptive name.
///
/// **Known problems:** None?
///
/// **Example:**
///
/// ```rust
/// let (a, b, c, d, e, f, g) = (...);
/// ```

10
clippy_lints/src/open_options.rs
View File

@ -4,13 +4,13 @@ use syntax::ast::LitKind;
use syntax::codemap::{Span, Spanned};
use utils::{match_type, paths, span_lint, walk_ptrs_ty_depth};
/// **What it does:** This lint checks for duplicate open options as well as combinations that make
/// no sense.
/// **What it does:** Checks for duplicate open options as well as combinations
/// that make no sense.
///
/// **Why is this bad?** In the best case, the code will be harder to read than necessary. I don't
/// know the worst case.
/// **Why is this bad?** In the best case, the code will be harder to read than
/// necessary. I don't know the worst case.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

6
clippy_lints/src/overflow_check_conditional.rs
View File

@ -2,10 +2,10 @@ use rustc::lint::*;
use rustc::hir::*;
use utils::span_lint;
/// **What it does:** This lint finds classic underflow / overflow checks.
/// **What it does:** Detects classic underflow/overflow checks.
///
/// **Why is this bad?** Most classic C underflow / overflow checks will fail in Rust. Users can
/// use functions like `overflowing_*` and `wrapping_*` instead.
/// **Why is this bad?** Most classic C underflow/overflow checks will fail in
/// Rust. Users can use functions like `overflowing_*` and `wrapping_*` instead.
///
/// **Known problems:** None.
///

11
clippy_lints/src/panic.rs
View File

@ -3,10 +3,15 @@ use rustc::lint::*;
use syntax::ast::LitKind;
use utils::{is_direct_expn_of, match_path, paths, span_lint};
/// **What it does:** This lint checks for missing parameters in `panic!`.
/// **What it does:** Checks for missing parameters in `panic!`.
///
/// **Known problems:** Should you want to use curly brackets in `panic!` without any parameter,
/// this lint will warn.
/// **Why is this bad?** Contrary to the `format!` family of macros, there are
/// two forms of `panic!`: if there are no parameters given, the first argument
/// is not a format string and used literally. So while `format!("{}")` will
/// fail to compile, `panic!("{}")` will not.
///
/// **Known problems:** Should you want to use curly brackets in `panic!`
/// without any parameter, this lint will warn.
///
/// **Example:**
/// ```rust

13
clippy_lints/src/precedence.rs
View File

@ -3,18 +3,19 @@ use syntax::ast::*;
use syntax::codemap::Spanned;
use utils::{span_lint, snippet};
/// **What it does:** This lint checks for operations where precedence may be unclear and suggests
/// to add parentheses. Currently it catches the following:
/// **What it does:** Checks for operations where precedence may be unclear
/// and suggests to add parentheses. Currently it catches the following:
/// * mixed usage of arithmetic and bit shifting/combining operators without parentheses
/// * a "negative" numeric literal (which is really a unary `-` followed by a numeric literal)
/// followed by a method call
///
/// **Why is this bad?** Because not everyone knows the precedence of those operators by heart, so
/// expressions like these may trip others trying to reason about the code.
/// **Why is this bad?** Not everyone knows the precedence of those operators by
/// heart, so expressions like these may trip others trying to reason about the
/// code.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Examples:**
/// **Example:**
/// * `1 << 2 + 3` equals 32, while `(1 << 2) + 3` equals 7
/// * `-1i32.abs()` equals -1, while `(-1i32).abs()` equals 1
declare_lint! {

16
clippy_lints/src/print.rs
View File

@ -4,11 +4,11 @@ use rustc::lint::*;
use utils::paths;
use utils::{is_expn_of, match_path, span_lint};
/// **What it does:** This lint warns whenever you print on *stdout*. The purpose of this lint is
/// to catch debugging remnants.
/// **What it does:** Checks for printing on *stdout*. The purpose of this lint
/// is to catch debugging remnants.
///
/// **Why is this bad?** People often print on *stdout* while debugging an application and might
/// forget to remove those prints afterward.
/// **Why is this bad?** People often print on *stdout* while debugging an
/// application and might forget to remove those prints afterward.
///
/// **Known problems:** Only catches `print!` and `println!` calls.
///
@ -22,11 +22,11 @@ declare_lint! {
"printing on stdout"
}
/// **What it does:** This lint warns whenever you use `Debug` formatting. The purpose of this lint
/// is to catch debugging remnants.
/// **What it does:** Checks for use of `Debug` formatting. The purpose of this
/// lint is to catch debugging remnants.
///
/// **Why is this bad?** The purpose of the `Debug` trait is to facilitate debugging Rust code. It
/// should not be used in in user-facing output.
/// **Why is this bad?** The purpose of the `Debug` trait is to facilitate
/// debugging Rust code. It should not be used in in user-facing output.
///
/// **Example:**
/// ```rust

12
clippy_lints/src/ptr_arg.rs
View File

@ -7,14 +7,14 @@ use rustc::ty;
use syntax::ast::NodeId;
use utils::{match_type, paths, span_lint};
/// **What it does:** This lint checks for function arguments of type `&String` or `&Vec` unless
/// the references are mutable.
/// **What it does:** Checks for function arguments of type `&String` or `&Vec`
/// unless the references are mutable.
///
/// **Why is this bad?** Requiring the argument to be of the specific size makes the function less
/// useful for no benefit; slices in the form of `&[T]` or `&str` usually suffice and can be
/// obtained from other types, too.
/// **Why is this bad?** Requiring the argument to be of the specific size makes
/// the function less useful for no benefit; slices in the form of `&[T]` or
/// `&str` usually suffice and can be obtained from other types, too.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

14
clippy_lints/src/ranges.rs
View File

@ -4,13 +4,13 @@ use syntax::codemap::Spanned;
use utils::{is_integer_literal, match_type, paths, snippet, span_lint};
use utils::higher;
/// **What it does:** This lint checks for iterating over ranges with a `.step_by(0)`, which never
/// terminates.
/// **What it does:** Checks for iterating over ranges with a `.step_by(0)`,
/// which never terminates.
///
/// **Why is this bad?** This very much looks like an oversight, since with `loop { .. }` there is
/// an obvious better way to endlessly loop.
/// **Why is this bad?** This very much looks like an oversight, since with
/// `loop { .. }` there is an obvious better way to endlessly loop.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -20,11 +20,11 @@ declare_lint! {
pub RANGE_STEP_BY_ZERO, Warn,
"using Range::step_by(0), which produces an infinite iterator"
}
/// **What it does:** This lint checks for zipping a collection with the range of `0.._.len()`.
/// **What it does:** Checks for zipping a collection with the range of `0.._.len()`.
///
/// **Why is this bad?** The code is better expressed with `.enumerate()`.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

22
clippy_lints/src/regex.rs
View File

@ -11,8 +11,8 @@ use syntax::codemap::{Span, BytePos};
use syntax::parse::token::InternedString;
use utils::{is_expn_of, match_def_path, match_type, paths, span_lint, span_help_and_lint};
/// **What it does:** This lint checks [regex] creation (with `Regex::new`, `RegexBuilder::new` or
/// `RegexSet::new`) for correct regex syntax.
/// **What it does:** Checks [regex] creation (with `Regex::new`,
/// `RegexBuilder::new` or `RegexSet::new`) for correct regex syntax.
///
/// [regex]: https://crates.io/crates/regex
///
@ -30,13 +30,14 @@ declare_lint! {
"finds invalid regular expressions"
}
/// **What it does:** This lint checks for trivial [regex] creation (with `Regex::new`,
/// **What it does:** Checks for trivial [regex] creation (with `Regex::new`,
/// `RegexBuilder::new` or `RegexSet::new`).
///
/// [regex]: https://crates.io/crates/regex
///
/// **Why is this bad?** This can likely be replaced by `==` or `str::starts_with`,
/// `str::ends_with` or `std::contains` or other `str` methods.
/// **Why is this bad?** Matching the regex can likely be replaced by `==` or
/// `str::starts_with`, `str::ends_with` or `std::contains` or other `str`
/// methods.
///
/// **Known problems:** None.
///
@ -50,13 +51,14 @@ declare_lint! {
"finds trivial regular expressions"
}
/// **What it does:** This lint checks for usage of `regex!(_)` which as of now is usually slower
/// than `Regex::new(_)` unless called in a loop (which is a bad idea anyway).
/// **What it does:** Checks for usage of `regex!(_)` which (as of now) is
/// usually slower than `Regex::new(_)` unless called in a loop (which is a bad
/// idea anyway).
///
/// **Why is this bad?** Performance, at least for now. The macro version is likely to catch up
/// long-term, but for now the dynamic version is faster.
/// **Why is this bad?** Performance, at least for now. The macro version is
/// likely to catch up long-term, but for now the dynamic version is faster.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust

24
clippy_lints/src/returns.rs
View File

@ -5,13 +5,15 @@ use syntax::visit::FnKind;
use utils::{span_note_and_lint, span_lint_and_then, snippet_opt, match_path_ast, in_external_macro};
/// **What it does:** This lint checks for return statements at the end of a block.
/// **What it does:** Checks for return statements at the end of a block.
///
/// **Why is this bad?** Removing the `return` and semicolon will make the code more rusty.
/// **Why is this bad?** Removing the `return` and semicolon will make the code
/// more rusty.
///
/// **Known problems:** Following this lint's advice may currently run afoul of Rust issue
/// [#31439](https://github.com/rust-lang/rust/issues/31439), so if you get lifetime errors, please
/// roll back the change until that issue is fixed.
/// **Known problems:** Following this lint's advice may currently run afoul of
/// Rust issue [#31439](https://github.com/rust-lang/rust/issues/31439), so if
/// you get lifetime errors, please roll back the change until that issue is
/// fixed.
///
/// **Example:**
/// ```rust
@ -22,13 +24,15 @@ declare_lint! {
"using a return statement like `return expr;` where an expression would suffice"
}
/// **What it does:** This lint checks for `let`-bindings, which are subsequently returned.
/// **What it does:** Checks for `let`-bindings, which are subsequently returned.
///
/// **Why is this bad?** It is just extraneous code. Remove it to make your code more rusty.
/// **Why is this bad?** It is just extraneous code. Remove it to make your code
/// more rusty.
///
/// **Known problems:** Following this lint's advice may currently run afoul of Rust issue
/// [#31439](https://github.com/rust-lang/rust/issues/31439), so if you get lifetime errors, please
/// roll back the change until that issue is fixed.
/// **Known problems:** Following this lint's advice may currently run afoul of
/// Rust issue [#31439](https://github.com/rust-lang/rust/issues/31439), so if
/// you get lifetime errors, please roll back the change until that issue is
/// fixed.
///
/// **Example:**
/// ```rust

7
clippy_lints/src/serde.rs
View File

@ -2,13 +2,14 @@ use rustc::lint::*;
use rustc::hir::*;
use utils::{span_lint, get_trait_def_id, paths};
/// **What it does:** This lint checks for mis-uses of the serde API
/// **What it does:** Checks for mis-uses of the serde API.
///
/// **Why is this bad?** Serde is very finnicky about how its API should be used, but the type system can't be used to enforce it (yet)
/// **Why is this bad?** Serde is very finnicky about how its API should be
/// used, but the type system can't be used to enforce it (yet).
///
/// **Known problems:** None.
///
/// **Example:** implementing `Visitor::visit_string` but not `Visitor::visit_str`
/// **Example:** Implementing `Visitor::visit_string` but not `Visitor::visit_str`.
declare_lint! {
pub SERDE_API_MISUSE, Warn,
"Various things that will negatively affect your serde experience"

45
clippy_lints/src/shadow.rs
View File

@ -7,14 +7,15 @@ use std::ops::Deref;
use syntax::codemap::Span;
use utils::{higher, in_external_macro, snippet, span_lint_and_then};
/// **What it does:** This lint checks for bindings that shadow other bindings already in scope,
/// while just changing reference level or mutability.
/// **What it does:** Checks for bindings that shadow other bindings already in
/// scope, while just changing reference level or mutability.
///
/// **Why is this bad?** Not much, in fact it's a very common pattern in Rust code. Still, some may
/// opt to avoid it in their code base, they can set this lint to `Warn`.
/// **Why is this bad?** Not much, in fact it's a very common pattern in Rust
/// code. Still, some may opt to avoid it in their code base, they can set this
/// lint to `Warn`.
///
/// **Known problems:** This lint, as the other shadowing related lints, currently only catches
/// very simple patterns.
/// **Known problems:** This lint, as the other shadowing related lints,
/// currently only catches very simple patterns.
///
/// **Example:**
/// ```rust
@ -25,15 +26,16 @@ declare_lint! {
"rebinding a name to itself, e.g. `let mut x = &mut x`"
}
/// **What it does:** This lint checks for bindings that shadow other bindings already in scope,
/// while reusing the original value.
/// **What it does:** Checks for bindings that shadow other bindings already in
/// scope, while reusing the original value.
///
/// **Why is this bad?** Not too much, in fact it's a common pattern in Rust code. Still, some
/// argue that name shadowing like this hurts readability, because a value may be bound to
/// different things depending on position in the code.
/// **Why is this bad?** Not too much, in fact it's a common pattern in Rust
/// code. Still, some argue that name shadowing like this hurts readability,
/// because a value may be bound to different things depending on position in
/// the code.
///
/// **Known problems:** This lint, as the other shadowing related lints, currently only catches
/// very simple patterns.
/// **Known problems:** This lint, as the other shadowing related lints,
/// currently only catches very simple patterns.
///
/// **Example:**
/// ```rust
@ -45,16 +47,17 @@ declare_lint! {
`let x = x + 1`"
}
/// **What it does:** This lint checks for bindings that shadow other bindings already in scope,
/// either without a initialization or with one that does not even use the original value.
/// **What it does:** Checks for bindings that shadow other bindings already in
/// scope, either without a initialization or with one that does not even use
/// the original value.
///
/// **Why is this bad?** Name shadowing can hurt readability, especially in large code bases,
/// because it is easy to lose track of the active binding at any place in the code. This can be
/// alleviated by either giving more specific names to bindings ore introducing more scopes to
/// contain the bindings.
/// **Why is this bad?** Name shadowing can hurt readability, especially in
/// large code bases, because it is easy to lose track of the active binding at
/// any place in the code. This can be alleviated by either giving more specific
/// names to bindings ore introducing more scopes to contain the bindings.
///
/// **Known problems:** This lint, as the other shadowing related lints, currently only catches
/// very simple patterns.
/// **Known problems:** This lint, as the other shadowing related lints,
/// currently only catches very simple patterns.
///
/// **Example:**
/// ```rust

39
clippy_lints/src/strings.rs
View File

@ -4,10 +4,11 @@ use syntax::codemap::Spanned;
use utils::SpanlessEq;
use utils::{match_type, paths, span_lint, span_lint_and_then, walk_ptrs_ty, get_parent_expr};
/// **What it does:** This lint matches code of the form `x = x + y` (without `let`!).
/// **What it does:** Checks for string appends of the form `x = x + y` (without
/// `let`!).
///
/// **Why is this bad?** It's not really bad, but some people think that the `.push_str(_)` method
/// is more readable.
/// **Why is this bad?** It's not really bad, but some people think that the
/// `.push_str(_)` method is more readable.
///
/// **Known problems:** None.
///
@ -23,18 +24,21 @@ declare_lint! {
"using `x = x + ..` where x is a `String`; suggests using `push_str()` instead"
}
/// **What it does:** The `string_add` lint matches all instances of `x + _` where `x` is of type
/// `String`, but only if [`string_add_assign`](#string_add_assign) does *not* match.
/// **What it does:** Checks for all instances of `x + _` where `x` is of type
/// `String`, but only if [`string_add_assign`](#string_add_assign) does *not*
/// match.
///
/// **Why is this bad?** It's not bad in and of itself. However, this particular `Add`
/// implementation is asymmetric (the other operand need not be `String`, but `x` does), while
/// addition as mathematically defined is symmetric, also the `String::push_str(_)` function is a
/// perfectly good replacement. Therefore some dislike it and wish not to have it in their code.
/// **Why is this bad?** It's not bad in and of itself. However, this particular
/// `Add` implementation is asymmetric (the other operand need not be `String`,
/// but `x` does), while addition as mathematically defined is symmetric, also
/// the `String::push_str(_)` function is a perfectly good replacement.
/// Therefore some dislike it and wish not to have it in their code.
///
/// That said, other people think that string addition, having a long tradition in other languages
/// is actually fine, which is why we decided to make this particular lint `allow` by default.
/// That said, other people think that string addition, having a long tradition
/// in other languages is actually fine, which is why we decided to make this
/// particular lint `allow` by default.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
///
@ -48,14 +52,15 @@ declare_lint! {
"using `x + ..` where x is a `String`; suggests using `push_str()` instead"
}
/// **What it does:** This lint matches the `as_bytes` method called on string
/// literals that contain only ASCII characters.
/// **What it does:** Checks for the `as_bytes` method called on string literals
/// that contain only ASCII characters.
///
/// **Why is this bad?** Byte string literals (e.g. `b"foo"`) can be used instead. They are shorter
/// but less discoverable than `as_bytes()`.
/// **Why is this bad?** Byte string literals (e.g. `b"foo"`) can be used
/// instead. They are shorter but less discoverable than `as_bytes()`.
///
/// **Known Problems:** None.
///
/// **Example:**
///
/// ```rust
/// let bs = "a byte string".as_bytes();
/// ```

8
clippy_lints/src/swap.rs
View File

@ -5,10 +5,10 @@ use syntax::codemap::mk_sp;
use utils::{differing_macro_contexts, match_type, paths, snippet, span_lint_and_then, walk_ptrs_ty, SpanlessEq};
use utils::sugg::Sugg;
/// **What it does:** This lints manual swapping.
/// **What it does:** Checks for manual swapping.
///
/// **Why is this bad?** The `std::mem::swap` function exposes the intent better without
/// deinitializing or copying either variable.
/// **Why is this bad?** The `std::mem::swap` function exposes the intent better
/// without deinitializing or copying either variable.
///
/// **Known problems:** None.
///
@ -24,7 +24,7 @@ declare_lint! {
"manual swap"
}
/// **What it does:** This lints `foo = bar; bar = foo` sequences.
/// **What it does:** Checks for `foo = bar; bar = foo` sequences.
///
/// **Why is this bad?** This looks like a failed attempt to swap.
///

8
clippy_lints/src/temporary_assignment.rs
View File

@ -3,11 +3,11 @@ use rustc::hir::{Expr, ExprAssign, ExprField, ExprStruct, ExprTup, ExprTupField}
use utils::is_adjusted;
use utils::span_lint;
/// **What it does:** This lint checks for construction of a structure or tuple just to assign a
/// value in it.
/// **What it does:** Checks for construction of a structure or tuple just to
/// assign a value in it.
///
/// **Why is this bad?** Readability. If the structure is only created to be updated, why not write
/// the structure you want in the first place?
/// **Why is this bad?** Readability. If the structure is only created to be
/// updated, why not write the structure you want in the first place?
///
/// **Known problems:** None.
///

24
clippy_lints/src/transmute.rs
View File

@ -5,12 +5,13 @@ use rustc::hir::*;
use utils::{match_def_path, paths, span_lint, span_lint_and_then};
use utils::sugg;
/// **What it does:** This lint checks for transmutes that can't ever be correct on any architecture
/// **What it does:** Checks for transmutes that can't ever be correct on any
/// architecture.
///
/// **Why is this bad?** It's basically guaranteed to be undefined behaviour
/// **Why is this bad?** It's basically guaranteed to be undefined behaviour.
///
/// **Known problems:** When accessing C, users might want to store pointer sized objects in
/// `extradata` arguments to save an allocation.
/// **Known problems:** When accessing C, users might want to store pointer
/// sized objects in `extradata` arguments to save an allocation.
///
/// **Example:**
/// ```rust
@ -22,11 +23,11 @@ declare_lint! {
"transmutes that are confusing at best, undefined behaviour at worst and always useless"
}
/// **What it does:** This lint checks for transmutes to the original type of the object and
/// transmutes that could be a cast.
/// **What it does:** Checks for transmutes to the original type of the object
/// and transmutes that could be a cast.
///
/// **Why is this bad?** Readability. The code tricks people into thinking that something complex
/// is going on
/// **Why is this bad?** Readability. The code tricks people into thinking that
/// something complex is going on.
///
/// **Known problems:** None.
///
@ -40,9 +41,10 @@ declare_lint! {
"transmutes that have the same to and from types or could be a cast/coercion"
}
/// **What it does:*** This lint checks for transmutes between a type `T` and `*T`.
/// **What it does:** Checks for transmutes between a type `T` and `*T`.
///
/// **Why is this bad?** It's easy to mistakenly transmute between a type and a pointer to that type.
/// **Why is this bad?** It's easy to mistakenly transmute between a type and a
/// pointer to that type.
///
/// **Known problems:** None.
///
@ -56,7 +58,7 @@ declare_lint! {
"transmutes that have to or from types that are a pointer to the other"
}
/// **What it does:*** This lint checks for transmutes from a pointer to a reference.
/// **What it does:** Checks for transmutes from a pointer to a reference.
///
/// **Why is this bad?** This can always be rewritten with `&` and `*`.
///

173
clippy_lints/src/types.rs
View File

@ -14,12 +14,13 @@ use utils::paths;
#[allow(missing_copy_implementations)]
pub struct TypePass;
/// **What it does:** This lint checks for use of `Box<Vec<_>>` anywhere in the code.
/// **What it does:** Checks for use of `Box<Vec<_>>` anywhere in the code.
///
/// **Why is this bad?** `Vec` already keeps its contents in a separate area on the heap. So if you
/// `Box` it, you just add another level of indirection without any benefit whatsoever.
/// **Why is this bad?** `Vec` already keeps its contents in a separate area on
/// the heap. So if you `Box` it, you just add another level of indirection
/// without any benefit whatsoever.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -32,8 +33,8 @@ declare_lint! {
"usage of `Box<Vec<T>>`, vector elements are already on the heap"
}
/// **What it does:** This lint checks for usage of any `LinkedList`, suggesting to use a `Vec` or
/// a `VecDeque` (formerly called `RingBuf`).
/// **What it does:** Checks for usage of any `LinkedList`, suggesting to use a
/// `Vec` or a `VecDeque` (formerly called `RingBuf`).
///
/// **Why is this bad?** Gankro says:
///
@ -47,8 +48,8 @@ declare_lint! {
/// > if you're doing a lot of insertion in the middle of the list, `RingBuf` can still be better
/// > because of how expensive it is to seek to the middle of a `LinkedList`.
///
/// **Known problems:** False positives – the instances where using a `LinkedList` makes sense are
/// few and far between, but they can still happen.
/// **Known problems:** False positives – the instances where using a
/// `LinkedList` makes sense are few and far between, but they can still happen.
///
/// **Example:**
/// ```rust
@ -104,13 +105,17 @@ impl LateLintPass for TypePass {
#[allow(missing_copy_implementations)]
pub struct LetPass;
/// **What it does:** This lint checks for binding a unit value.
/// **What it does:** Checks for binding a unit value.
///
/// **Why is this bad?** A unit value cannot usefully be used anywhere. So binding one is kind of pointless.
/// **Why is this bad?** A unit value cannot usefully be used anywhere. So
/// binding one is kind of pointless.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `let x = { 1; };`
/// **Example:**
/// ```rust
/// let x = { 1; };
/// ```
declare_lint! {
pub LET_UNIT_VALUE, Warn,
"creating a let binding to a value of unit type, which usually can't be used afterwards"
@ -147,13 +152,22 @@ impl LateLintPass for LetPass {
}
}
/// **What it does:** This lint checks for comparisons to unit.
/// **What it does:** Checks for comparisons to unit.
///
/// **Why is this bad?** Unit is always equal to itself, and thus is just a clumsily written constant. Mostly this happens when someone accidentally adds semicolons at the end of the operands.
/// **Why is this bad?** Unit is always equal to itself, and thus is just a
/// clumsily written constant. Mostly this happens when someone accidentally
/// adds semicolons at the end of the operands.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `if { foo(); } == { bar(); } { baz(); }` is equal to `{ foo(); bar(); baz(); }`
/// **Example:**
/// ```rust
/// if { foo(); } == { bar(); } { baz(); }
/// ```
/// is equal to
/// ```rust
/// { foo(); bar(); baz(); }
/// ```
declare_lint! {
pub UNIT_CMP, Warn,
"comparing unit values (which is always `true` or `false`, respectively)"
@ -194,51 +208,85 @@ impl LateLintPass for UnitCmp {
pub struct CastPass;
/// **What it does:** This lint checks for casts from any numerical to a float type where the receiving type cannot store all values from the original type without rounding errors. This possible rounding is to be expected, so this lint is `Allow` by default.
/// **What it does:** Checks for casts from any numerical to a float type where
/// the receiving type cannot store all values from the original type without
/// rounding errors. This possible rounding is to be expected, so this lint is
/// `Allow` by default.
///
/// Basically, this warns on casting any integer with 32 or more bits to `f32` or any 64-bit integer to `f64`.
/// Basically, this warns on casting any integer with 32 or more bits to `f32`
/// or any 64-bit integer to `f64`.
///
/// **Why is this bad?** It's not bad at all. But in some applications it can be helpful to know where precision loss can take place. This lint can help find those places in the code.
/// **Why is this bad?** It's not bad at all. But in some applications it can be
/// helpful to know where precision loss can take place. This lint can help find
/// those places in the code.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `let x = u64::MAX; x as f64`
/// **Example:**
/// ```rust
/// let x = u64::MAX; x as f64
/// ```
declare_lint! {
pub CAST_PRECISION_LOSS, Allow,
"casts that cause loss of precision, e.g `x as f32` where `x: u64`"
}
/// **What it does:** This lint checks for casts from a signed to an unsigned numerical type. In this case, negative values wrap around to large positive values, which can be quite surprising in practice. However, as the cast works as defined, this lint is `Allow` by default.
/// **What it does:** Checks for casts from a signed to an unsigned numerical
/// type. In this case, negative values wrap around to large positive values,
/// which can be quite surprising in practice. However, as the cast works as
/// defined, this lint is `Allow` by default.
///
/// **Why is this bad?** Possibly surprising results. You can activate this lint as a one-time check to see where numerical wrapping can arise.
/// **Why is this bad?** Possibly surprising results. You can activate this lint
/// as a one-time check to see where numerical wrapping can arise.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `let y : i8 = -1; y as u64` will return 18446744073709551615
/// **Example:**
/// ```rust
/// let y: i8 = -1;
/// y as u64 // will return 18446744073709551615
/// ```
declare_lint! {
pub CAST_SIGN_LOSS, Allow,
"casts from signed types to unsigned types, e.g `x as u32` where `x: i32`"
}
/// **What it does:** This lint checks for on casts between numerical types that may truncate large values. This is expected behavior, so the cast is `Allow` by default.
/// **What it does:** Checks for on casts between numerical types that may
/// truncate large values. This is expected behavior, so the cast is `Allow` by
/// default.
///
/// **Why is this bad?** In some problem domains, it is good practice to avoid truncation. This lint can be activated to help assess where additional checks could be beneficial.
/// **Why is this bad?** In some problem domains, it is good practice to avoid
/// truncation. This lint can be activated to help assess where additional
/// checks could be beneficial.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `fn as_u8(x: u64) -> u8 { x as u8 }`
/// **Example:**
/// ```rust
/// fn as_u8(x: u64) -> u8 { x as u8 }
/// ```
declare_lint! {
pub CAST_POSSIBLE_TRUNCATION, Allow,
"casts that may cause truncation of the value, e.g `x as u8` where `x: u32`, or `x as i32` where `x: f32`"
}
/// **What it does:** This lint checks for casts from an unsigned type to a signed type of the same size. Performing such a cast is a 'no-op' for the compiler, i.e. nothing is changed at the bit level, and the binary representation of the value is reinterpreted. This can cause wrapping if the value is too big for the target signed type. However, the cast works as defined, so this lint is `Allow` by default.
/// **What it does:** Checks for casts from an unsigned type to a signed type of
/// the same size. Performing such a cast is a 'no-op' for the compiler,
/// i.e. nothing is changed at the bit level, and the binary representation of
/// the value is reinterpreted. This can cause wrapping if the value is too big
/// for the target signed type. However, the cast works as defined, so this lint
/// is `Allow` by default.
///
/// **Why is this bad?** While such a cast is not bad in itself, the results can be surprising when this is not the intended behavior, as demonstrated by the example below.
/// **Why is this bad?** While such a cast is not bad in itself, the results can
/// be surprising when this is not the intended behavior, as demonstrated by the
/// example below.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `u32::MAX as i32` will yield a value of `-1`.
/// **Example:**
/// ```rust
/// u32::MAX as i32 // will yield a value of `-1`
/// ```
declare_lint! {
pub CAST_POSSIBLE_WRAP, Allow,
"casts that may cause wrapping around the value, e.g `x as i32` where `x: u32` and `x > i32::MAX`"
@ -433,13 +481,18 @@ impl LateLintPass for CastPass {
}
}
/// **What it does:** This lint checks for types used in structs, parameters and `let` declarations above a certain complexity threshold.
/// **What it does:** Checks for types used in structs, parameters and `let`
/// declarations above a certain complexity threshold.
///
/// **Why is this bad?** Too complex types make the code less readable. Consider using a `type` definition to simplify them.
/// **Why is this bad?** Too complex types make the code less readable. Consider
/// using a `type` definition to simplify them.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `struct Foo { inner: Rc<Vec<Vec<Box<(u32, u32, u32, u32)>>>> }`
/// **Example:**
/// ```rust
/// struct Foo { inner: Rc<Vec<Vec<Box<(u32, u32, u32, u32)>>>> }
/// ```
declare_lint! {
pub TYPE_COMPLEXITY, Warn,
"usage of very complex types; recommends factoring out parts into `type` definitions"
@ -575,13 +628,21 @@ impl<'v> Visitor<'v> for TypeComplexityVisitor {
}
}
/// **What it does:** This lint points out expressions where a character literal is casted to `u8` and suggests using a byte literal instead.
/// **What it does:** Checks for expressions where a character literal is cast
/// to `u8` and suggests using a byte literal instead.
///
/// **Why is this bad?** In general, casting values to smaller types is error-prone and should be avoided where possible. In the particular case of converting a character literal to u8, it is easy to avoid by just using a byte literal instead. As an added bonus, `b'a'` is even slightly shorter than `'a' as u8`.
/// **Why is this bad?** In general, casting values to smaller types is
/// error-prone and should be avoided where possible. In the particular case of
/// converting a character literal to u8, it is easy to avoid by just using a
/// byte literal instead. As an added bonus, `b'a'` is even slightly shorter
/// than `'a' as u8`.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `'x' as u8`
/// **Example:**
/// ```rust
/// 'x' as u8
/// ```
declare_lint! {
pub CHAR_LIT_AS_U8, Warn,
"Casting a character literal to u8"
@ -617,13 +678,22 @@ impl LateLintPass for CharLitAsU8 {
}
}
/// **What it does:** This lint checks for comparisons where one side of the relation is either the minimum or maximum value for its type and warns if it involves a case that is always true or always false. Only integer and boolean types are checked.
/// **What it does:** Checks for comparisons where one side of the relation is
/// either the minimum or maximum value for its type and warns if it involves a
/// case that is always true or always false. Only integer and boolean types are
/// checked.
///
/// **Why is this bad?** An expression like `min <= x` may misleadingly imply that is is possible for `x` to be less than the minimum. Expressions like `max < x` are probably mistakes.
/// **Why is this bad?** An expression like `min <= x` may misleadingly imply
/// that is is possible for `x` to be less than the minimum. Expressions like
/// `max < x` are probably mistakes.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** `vec.len() <= 0`, `100 > std::i32::MAX`
/// **Example:**
/// ```rust
/// vec.len() <= 0
/// 100 > std::i32::MAX
/// ```
declare_lint! {
pub ABSURD_EXTREME_COMPARISONS, Warn,
"a comparison involving a maximum or minimum value involves a case that is always \
@ -787,13 +857,20 @@ impl LateLintPass for AbsurdExtremeComparisons {
}
}
/// **What it does:** This lint checks for comparisons where the relation is always either true or false, but where one side has been upcast so that the comparison is necessary. Only integer types are checked.
/// **What it does:** Checks for comparisons where the relation is always either
/// true or false, but where one side has been upcast so that the comparison is
/// necessary. Only integer types are checked.
///
/// **Why is this bad?** An expression like `let x : u8 = ...; (x as u32) > 300` will mistakenly imply that it is possible for `x` to be outside the range of `u8`.
/// **Why is this bad?** An expression like `let x : u8 = ...; (x as u32) > 300`
/// will mistakenly imply that it is possible for `x` to be outside the range of
/// `u8`.
///
/// **Known problems:** https://github.com/Manishearth/rust-clippy/issues/886
///
/// **Example:** `let x : u8 = ...; (x as u32) > 300`
/// **Example:**
/// ```rust
/// let x : u8 = ...; (x as u32) > 300
/// ```
declare_lint! {
pub INVALID_UPCAST_COMPARISONS, Allow,
"a comparison involving an upcast which is always true or false"

35
clippy_lints/src/unicode.rs
View File

@ -5,12 +5,12 @@ use syntax::codemap::Span;
use unicode_normalization::UnicodeNormalization;
use utils::{snippet, span_help_and_lint};
/// **What it does:** This lint checks for the Unicode zero-width space in the code.
/// **What it does:** Checks for the Unicode zero-width space in the code.
///
/// **Why is this bad?** Having an invisible character in the code makes for all sorts of April
/// fools, but otherwise is very much frowned upon.
/// **Why is this bad?** Having an invisible character in the code makes for all
/// sorts of April fools, but otherwise is very much frowned upon.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:** You don't see it, but there may be a zero-width space somewhere in this text.
declare_lint! {
@ -18,14 +18,15 @@ declare_lint! {
"using a zero-width space in a string literal, which is confusing"
}
/// **What it does:** This lint checks for non-ASCII characters in string literals.
/// **What it does:** Checks for non-ASCII characters in string literals.
///
/// **Why is this bad?** Yeah, we know, the 90's called and wanted their charset back. Even so,
/// there still are editors and other programs out there that don't work well with Unicode. So if
/// the code is meant to be used internationally, on multiple operating systems, or has other
/// portability requirements, activating this lint could be useful.
/// **Why is this bad?** Yeah, we know, the 90's called and wanted their charset
/// back. Even so, there still are editors and other programs out there that
/// don't work well with Unicode. So if the code is meant to be used
/// internationally, on multiple operating systems, or has other portability
/// requirements, activating this lint could be useful.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example:**
/// ```rust
@ -37,15 +38,17 @@ declare_lint! {
using the `\\u` escape instead"
}
/// **What it does:** This lint checks for string literals that contain Unicode in a form that is
/// not equal to its [NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).
/// **What it does:** Checks for string literals that contain Unicode in a form
/// that is not equal to its
/// [NFC-recomposition](http://www.unicode.org/reports/tr15/#Norm_Forms).
///
/// **Why is this bad?** If such a string is compared to another, the results may be surprising.
/// **Why is this bad?** If such a string is compared to another, the results
/// may be surprising.
///
/// **Known problems** None
/// **Known problems** None.
///
/// **Example:** You may not see it, but “à” and “à” aren't the same string. The former when
/// escaped is actually `"a\u{300}"` while the latter is `"\u{e0}"`.
/// **Example:** You may not see it, but “à” and “à” aren't the same string. The
/// former when escaped is actually `"a\u{300}"` while the latter is `"\u{e0}"`.
declare_lint! {
pub UNICODE_NOT_NFC, Allow,
"using a unicode literal not in NFC normal form (see \

6
clippy_lints/src/unsafe_removed_from_name.rs
View File

@ -5,9 +5,11 @@ use syntax::codemap::Span;
use syntax::parse::token::InternedString;
use utils::span_lint;
/// **What it does:** This lint checks for imports that remove "unsafe" from an item's name
/// **What it does:** Checks for imports that remove "unsafe" from an item's
/// name.
///
/// **Why is this bad?** Renaming makes it less clear which traits and structures are unsafe.
/// **Why is this bad?** Renaming makes it less clear which traits and
/// structures are unsafe.
///
/// **Known problems:** None.
///

6
clippy_lints/src/unused_label.rs
View File

@ -7,10 +7,10 @@ use syntax::codemap::Span;
use syntax::parse::token::InternedString;
use utils::{in_macro, span_lint};
/// **What it does:** This lint checks for unused labels.
/// **What it does:** Checks for unused labels.
///
/// **Why is this bad?** Maybe the label should be used in which case there is an error in the
/// code or it should be removed.
/// **Why is this bad?** Maybe the label should be used in which case there is
/// an error in the code or it should be removed.
///
/// **Known problems:** Hopefully none.
///

6
clippy_lints/src/utils/internal_lints.rs
View File

@ -3,13 +3,13 @@ use utils::span_lint;
use syntax::parse::token::InternedString;
use syntax::ast::*;
/// **What it does:** This lint checks for various things we like to keep tidy in clippy
/// **What it does:** Checks for various things we like to keep tidy in clippy.
///
/// **Why is this bad?** ???
/// **Why is this bad?** We like to pretend we're an example of tidy code.
///
/// **Known problems:** None.
///
/// **Example:** wrong ordering of the util::paths constants
/// **Example:** Wrong ordering of the util::paths constants.
declare_lint! {
pub CLIPPY_LINTS_INTERNAL, Allow,
"Various things that will negatively affect your clippy experience"

3
clippy_lints/src/vec.rs
View File

@ -6,7 +6,8 @@ use rustc_const_eval::eval_const_expr_partial;
use syntax::codemap::Span;
use utils::{higher, is_copy, snippet, span_lint_and_then};
/// **What it does:** This lint warns about using `&vec![..]` when using `&[..]` would be possible.
/// **What it does:** Checks for usage of `&vec![..]` when using `&[..]` would
/// be possible.
///
/// **Why is this bad?** This is less efficient.
///

15
clippy_lints/src/zero_div_zero.rs
View File

@ -3,18 +3,13 @@ use rustc::lint::*;
use rustc::hir::*;
use utils::span_help_and_lint;
/// `Pass` is a pass that checks for a binary expression that consists
/// `of 0.0/0.0`, which is always `NaN`. It is more clear to replace instances of
/// `0.0/0.0` with `std::f32::NaN` or `std::f64::NaN`, depending on the precision.
pub struct Pass;
/// **What it does:** This lint checks for `0.0 / 0.0`.
/// **What it does:** Checks for `0.0 / 0.0`.
///
/// **Why is this bad?** It's less readable than `std::f32::NAN` or `std::f64::NAN`
/// **Why is this bad?** It's less readable than `std::f32::NAN` or `std::f64::NAN`.
///
/// **Known problems:** None
/// **Known problems:** None.
///
/// **Example**
/// **Example:**
/// ```rust
/// 0.0f32 / 0.0
/// ```
@ -24,6 +19,8 @@ declare_lint! {
"usage of `0.0 / 0.0` to obtain NaN instead of std::f32::NaN or std::f64::NaN"
}
pub struct Pass;
impl LintPass for Pass {
fn get_lints(&self) -> LintArray {
lint_array!(ZERO_DIVIDED_BY_ZERO)