Standardize lint formulation

Author: bluthej

clippy_lints/src/allow_attributes.rs

@@ -6,7 +6,7 @@ use rustc_lint::{LateContext, LateLintPass};
 use rustc_session::{declare_lint_pass, declare_tool_lint};
 
 declare_clippy_lint! {
-    /// Detects uses of the `#[allow]` attribute and suggests replacing it with
+    /// Checks for usage of the `#[allow]` attribute and suggests replacing it with
     /// the `#[expect]` (See [RFC 2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html))
     ///
     /// The expect attribute is still unstable and requires the `lint_reasons`

clippy_lints/src/casts/mod.rs

@@ -506,7 +506,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for uses of the `abs()` method that cast the result to unsigned.
+    /// Checks for usage of the `abs()` method that cast the result to unsigned.
     ///
     /// ### Why is this bad?
     /// The `unsigned_abs()` method avoids panic when called on the MIN value.

clippy_lints/src/crate_in_macro_def.rs

@@ -9,7 +9,7 @@ use rustc_span::{symbol::sym, Span};
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of `crate` as opposed to `$crate` in a macro definition.
+    /// Checks for usage of `crate` as opposed to `$crate` in a macro definition.
     ///
     /// ### Why is this bad?
     /// `crate` refers to the macro call's crate, whereas `$crate` refers to the macro definition's

clippy_lints/src/entry.rs

@@ -19,7 +19,7 @@ use rustc_span::{Span, SyntaxContext, DUMMY_SP};
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for uses of `contains_key` + `insert` on `HashMap`
+    /// Checks for usage of `contains_key` + `insert` on `HashMap`
     /// or `BTreeMap`.
     ///
     /// ### Why is this bad?

clippy_lints/src/format_impl.rs

@@ -51,7 +51,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of `println`, `print`, `eprintln` or `eprint` in an
+    /// Checks for usage of `println`, `print`, `eprintln` or `eprint` in an
     /// implementation of a formatting trait.
     ///
     /// ### Why is this bad?

clippy_lints/src/formatting.rs

@@ -10,7 +10,7 @@ use rustc_span::source_map::Span;
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of the non-existent `=*`, `=!` and `=-`
+    /// Checks for usage of the non-existent `=*`, `=!` and `=-`
     /// operators.
     ///
     /// ### Why is this bad?

clippy_lints/src/lines_filter_map_ok.rs

@@ -10,7 +10,7 @@ use rustc_span::sym;
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Detect uses of `lines.filter_map(Result::ok)` or `lines.flat_map(Result::ok)`
+    /// Checks for usage of `lines.filter_map(Result::ok)` or `lines.flat_map(Result::ok)`
     /// when `lines` has type `std::io::Lines`.
     ///
     /// ### Why is this bad?

clippy_lints/src/manual_bits.rs

@@ -13,7 +13,7 @@ use rustc_span::sym;
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for uses of `std::mem::size_of::<T>() * 8` when
+    /// Checks for usage of `std::mem::size_of::<T>() * 8` when
     /// `T::BITS` is available.
     ///
     /// ### Why is this bad?

clippy_lints/src/matches/mod.rs

@@ -843,7 +843,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for usages of `Err(x)?`.
+    /// Checks for usage of `Err(x)?`.
     ///
     /// ### Why is this bad?
     /// The `?` operator is designed to allow calls that
@@ -878,7 +878,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for usages of `match` which could be implemented using `map`
+    /// Checks for usage of `match` which could be implemented using `map`
     ///
     /// ### Why is this bad?
     /// Using the `map` method is clearer and more concise.
@@ -902,7 +902,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for usages of `match` which could be implemented using `filter`
+    /// Checks for usage of `match` which could be implemented using `filter`
     ///
     /// ### Why is this bad?
     /// Using the `filter` method is clearer and more concise.

clippy_lints/src/methods/mod.rs

@@ -121,7 +121,7 @@ use rustc_span::{sym, Span};
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for usages of `cloned()` on an `Iterator` or `Option` where
+    /// Checks for usage of `cloned()` on an `Iterator` or `Option` where
     /// `copied()` could be used instead.
     ///
     /// ### Why is this bad?
@@ -201,7 +201,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for usages of `Iterator::flat_map()` where `filter_map()` could be
+    /// Checks for usage of `Iterator::flat_map()` where `filter_map()` could be
     /// used instead.
     ///
     /// ### Why is this bad?
@@ -441,7 +441,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for usages of `_.unwrap_or_else(Default::default)` on `Option` and
+    /// Checks for usage of `_.unwrap_or_else(Default::default)` on `Option` and
     /// `Result` values.
     ///
     /// ### Why is this bad?
@@ -1194,7 +1194,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of `.iter().nth()` (and the related
+    /// Checks for usage of `.iter().nth()` (and the related
     /// `.iter_mut().nth()`) on standard library types with *O*(1) element access.
     ///
     /// ### Why is this bad?
@@ -1221,7 +1221,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of `.skip(x).next()` on iterators.
+    /// Checks for usage of `.skip(x).next()` on iterators.
     ///
     /// ### Why is this bad?
     /// `.nth(x)` is cleaner
@@ -1246,7 +1246,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of `.drain(..)` on `Vec` and `VecDeque` for iteration.
+    /// Checks for usage of `.drain(..)` on `Vec` and `VecDeque` for iteration.
     ///
     /// ### Why is this bad?
     /// `.into_iter()` is simpler with better performance.
@@ -1271,7 +1271,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for using `x.get(x.len() - 1)` instead of
+    /// Checks for usage of `x.get(x.len() - 1)` instead of
     /// `x.last()`.
     ///
     /// ### Why is this bad?
@@ -1304,7 +1304,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of `.get().unwrap()` (or
+    /// Checks for usage of `.get().unwrap()` (or
     /// `.get_mut().unwrap`) on a standard library type which implements `Index`
     ///
     /// ### Why is this bad?
@@ -1475,7 +1475,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for using `fold` when a more succinct alternative exists.
+    /// Checks for usage of `fold` when a more succinct alternative exists.
     /// Specifically, this checks for `fold`s which could be replaced by `any`, `all`,
     /// `sum` or `product`.
     ///
@@ -2161,7 +2161,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for usages of `str::splitn(2, _)`
+    /// Checks for usage of `str::splitn(2, _)`
     ///
     /// ### Why is this bad?
     /// `split_once` is both clearer in intent and slightly more efficient.
@@ -2197,7 +2197,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for usages of `str::splitn` (or `str::rsplitn`) where using `str::split` would be the same.
+    /// Checks for usage of `str::splitn` (or `str::rsplitn`) where using `str::split` would be the same.
     /// ### Why is this bad?
     /// The function `split` is simpler and there is no performance difference in these cases, considering
     /// that both functions return a lazy iterator.
@@ -2251,7 +2251,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of `.collect::<Vec<String>>().join("")` on iterators.
+    /// Checks for usage of `.collect::<Vec<String>>().join("")` on iterators.
     ///
     /// ### Why is this bad?
     /// `.collect::<String>()` is more concise and might be more performant
@@ -2377,7 +2377,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for usages of `.then_some(..).unwrap_or(..)`
+    /// Checks for usage of `.then_some(..).unwrap_or(..)`
     ///
     /// ### Why is this bad?
     /// This can be written more clearly with `if .. else ..`
@@ -2553,7 +2553,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for using `x.get(0)` instead of
+    /// Checks for usage of `x.get(0)` instead of
     /// `x.first()`.
     ///
     /// ### Why is this bad?
@@ -2957,7 +2957,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Detects uses of `Vec::sort_by` passing in a closure
+    /// Checks for usage of `Vec::sort_by` passing in a closure
     /// which compares the two arguments, either directly or indirectly.
     ///
     /// ### Why is this bad?
@@ -3013,7 +3013,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of File::read_to_end and File::read_to_string.
+    /// Checks for usage of File::read_to_end and File::read_to_string.
     ///
     /// ### Why is this bad?
     /// `fs::{read, read_to_string}` provide the same functionality when `buf` is empty with fewer imports and no intermediate values.

clippy_lints/src/mutex_atomic.rs

@@ -1,4 +1,4 @@
-//! Checks for uses of mutex where an atomic value could be used
+//! Checks for usage of mutex where an atomic value could be used
 //!
 //! This lint is **allow** by default
 
@@ -12,7 +12,7 @@ use rustc_span::sym;
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for usages of `Mutex<X>` where an atomic will do.
+    /// Checks for usage of `Mutex<X>` where an atomic will do.
     ///
     /// ### Why is this bad?
     /// Using a mutex just to make access to a plain bool or
@@ -49,7 +49,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for usages of `Mutex<X>` where `X` is an integral
+    /// Checks for usage of `Mutex<X>` where `X` is an integral
     /// type.
     ///
     /// ### Why is this bad?

clippy_lints/src/non_copy_const.rs

@@ -1,4 +1,4 @@
-//! Checks for uses of const which the type is not `Freeze` (`Cell`-free).
+//! Checks for usage of const which the type is not `Freeze` (`Cell`-free).
 //!
 //! This lint is **warn** by default.
 

clippy_lints/src/operators/mod.rs

@@ -685,7 +685,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for uses of bitwise and/or operators between booleans, where performance may be improved by using
+    /// Checks for usage of bitwise and/or operators between booleans, where performance may be improved by using
     /// a lazy and.
     ///
     /// ### Why is this bad?

clippy_lints/src/types/mod.rs

@@ -22,7 +22,7 @@ use rustc_span::source_map::Span;
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of `Box<T>` where T is a collection such as Vec anywhere in the code.
+    /// Checks for usage of `Box<T>` where T is a collection such as Vec anywhere in the code.
     /// Check the [Box documentation](https://doc.rust-lang.org/std/boxed/index.html) for more information.
     ///
     /// ### Why is this bad?
@@ -52,7 +52,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of `Vec<Box<T>>` where T: Sized anywhere in the code.
+    /// Checks for usage of `Vec<Box<T>>` where T: Sized anywhere in the code.
     /// Check the [Box documentation](https://doc.rust-lang.org/std/boxed/index.html) for more information.
     ///
     /// ### Why is this bad?
@@ -85,7 +85,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of `Option<Option<_>>` in function signatures and type
+    /// Checks for usage of `Option<Option<_>>` in function signatures and type
     /// definitions
     ///
     /// ### Why is this bad?
@@ -164,7 +164,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of `&Box<T>` anywhere in the code.
+    /// Checks for usage of `&Box<T>` anywhere in the code.
     /// Check the [Box documentation](https://doc.rust-lang.org/std/boxed/index.html) for more information.
     ///
     /// ### Why is this bad?
@@ -190,7 +190,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of redundant allocations anywhere in the code.
+    /// Checks for usage of redundant allocations anywhere in the code.
     ///
     /// ### Why is this bad?
     /// Expressions such as `Rc<&T>`, `Rc<Rc<T>>`, `Rc<Arc<T>>`, `Rc<Box<T>>`, `Arc<&T>`, `Arc<Rc<T>>`,

clippy_lints/src/utils/internal_lints/unnecessary_def_path.rs

@@ -20,7 +20,7 @@ use std::str;
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for usages of def paths when a diagnostic item or a `LangItem` could be used.
+    /// Checks for usage of def paths when a diagnostic item or a `LangItem` could be used.
     ///
     /// ### Why is this bad?
     /// The path for an item is subject to change and is less efficient to look up than a

clippy_lints/src/write.rs

@@ -104,7 +104,7 @@ declare_clippy_lint! {
 
 declare_clippy_lint! {
     /// ### What it does
-    /// Checks for use of `Debug` formatting. The purpose of this
+    /// Checks for usage of `Debug` formatting. The purpose of this
     /// lint is to catch debugging remnants.
     ///
     /// ### Why is this bad?