};
declare_clippy_lint! {
- /// **What it does:** Checks for function arguments and let bindings denoted as
+ /// ### 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
+ /// ### 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
/// 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,
+ /// ### 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:**
+ /// ### Example
/// ```rust,ignore
/// // Bad
/// fn foo(ref x: u8) -> bool {
}
declare_clippy_lint! {
- /// **What it does:** 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
+ /// ### Why is this bad?
+ /// NaN does not compare meaningfully to anything – not
/// even itself – so those comparisons are simply wrong.
///
- /// **Known problems:** None.
- ///
- /// **Example:**
+ /// ### Example
/// ```rust
/// # let x = 1.0;
///
}
declare_clippy_lint! {
- /// **What it does:** Checks for (in-)equality comparisons on floating-point
+ /// ### 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
+ /// ### 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.
- ///
- /// **Example:**
+ /// ### Example
/// ```rust
/// let x = 1.2331f64;
/// let y = 1.2332f64;
}
declare_clippy_lint! {
- /// **What it does:** Checks for conversions to owned values just for the sake
+ /// ### 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
+ /// ### 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.
- ///
- /// **Example:**
+ /// ### Example
/// ```rust
/// # let x = "foo";
/// # let y = String::from("foo");
}
declare_clippy_lint! {
- /// **What it does:** Checks for getting the remainder of a division by one or minus
+ /// ### What it does
+ /// Checks for getting the remainder of a division by one or minus
/// one.
///
- /// **Why is this bad?** The result for a divisor of one can only ever be zero; for
+ /// ### Why is this bad?
+ /// The result for a divisor of one can only ever be zero; for
/// minus one it can cause panic/overflow (if the left operand is the minimal value of
/// the respective integer type) or results in 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.
- ///
- /// **Example:**
+ /// ### Example
/// ```rust
/// # let x = 1;
/// let a = x % 1;
}
declare_clippy_lint! {
- /// **What it does:** Checks for the use of bindings with a single leading
+ /// ### 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
+ /// ### 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
+ /// ### 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
}
declare_clippy_lint! {
- /// **What it does:** Checks for the use of short circuit boolean conditions as
+ /// ### What it does
+ /// Checks for the use of short circuit boolean conditions as
/// a
/// statement.
///
- /// **Why is this bad?** Using a short circuit boolean condition as a statement
+ /// ### Why is this bad?
+ /// Using a short circuit boolean condition as a statement
/// may hide the fact that the second part is executed or not depending on the
/// outcome of the first part.
///
- /// **Known problems:** None.
- ///
- /// **Example:**
+ /// ### Example
/// ```rust,ignore
/// f() && g(); // We should write `if f() { g(); }`.
/// ```
}
declare_clippy_lint! {
- /// **What it does:** Catch casts from `0` to some pointer type
+ /// ### What it does
+ /// Catch casts from `0` to some pointer type
///
- /// **Why is this bad?** This generally means `null` and is better expressed as
+ /// ### Why is this bad?
+ /// This generally means `null` and is better expressed as
/// {`std`, `core`}`::ptr::`{`null`, `null_mut`}.
///
- /// **Known problems:** None.
- ///
- /// **Example:**
- ///
+ /// ### Example
/// ```rust
/// // Bad
/// let a = 0 as *const u32;
}
declare_clippy_lint! {
- /// **What it does:** Checks for (in-)equality comparisons on floating-point
+ /// ### What it does
+ /// Checks for (in-)equality comparisons on floating-point
/// value and constant, 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
+ /// ### 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.
- ///
- /// **Example:**
+ /// ### Example
/// ```rust
/// let x: f64 = 1.0;
/// const ONE: f64 = 1.00;
projects / rust.git / blobdiff