@@ -121,7 +121,7 @@ use rustc_span::{sym, Span};
121121
122122declare_clippy_lint ! {
123123 /// ### What it does
124- /// Checks for usages of `cloned()` on an `Iterator` or `Option` where
124+ /// Checks for usage of `cloned()` on an `Iterator` or `Option` where
125125 /// `copied()` could be used instead.
126126 ///
127127 /// ### Why is this bad?
@@ -201,7 +201,7 @@ declare_clippy_lint! {
201201
202202declare_clippy_lint ! {
203203 /// ### What it does
204- /// Checks for usages of `Iterator::flat_map()` where `filter_map()` could be
204+ /// Checks for usage of `Iterator::flat_map()` where `filter_map()` could be
205205 /// used instead.
206206 ///
207207 /// ### Why is this bad?
@@ -441,7 +441,7 @@ declare_clippy_lint! {
441441
442442declare_clippy_lint ! {
443443 /// ### What it does
444- /// Checks for usages of `_.unwrap_or_else(Default::default)` on `Option` and
444+ /// Checks for usage of `_.unwrap_or_else(Default::default)` on `Option` and
445445 /// `Result` values.
446446 ///
447447 /// ### Why is this bad?
@@ -1194,7 +1194,7 @@ declare_clippy_lint! {
11941194
11951195declare_clippy_lint ! {
11961196 /// ### What it does
1197- /// Checks for use of `.iter().nth()` (and the related
1197+ /// Checks for usage of `.iter().nth()` (and the related
11981198 /// `.iter_mut().nth()`) on standard library types with *O*(1) element access.
11991199 ///
12001200 /// ### Why is this bad?
@@ -1221,7 +1221,7 @@ declare_clippy_lint! {
12211221
12221222declare_clippy_lint ! {
12231223 /// ### What it does
1224- /// Checks for use of `.skip(x).next()` on iterators.
1224+ /// Checks for usage of `.skip(x).next()` on iterators.
12251225 ///
12261226 /// ### Why is this bad?
12271227 /// `.nth(x)` is cleaner
@@ -1246,7 +1246,7 @@ declare_clippy_lint! {
12461246
12471247declare_clippy_lint ! {
12481248 /// ### What it does
1249- /// Checks for use of `.drain(..)` on `Vec` and `VecDeque` for iteration.
1249+ /// Checks for usage of `.drain(..)` on `Vec` and `VecDeque` for iteration.
12501250 ///
12511251 /// ### Why is this bad?
12521252 /// `.into_iter()` is simpler with better performance.
@@ -1271,7 +1271,7 @@ declare_clippy_lint! {
12711271
12721272declare_clippy_lint ! {
12731273 /// ### What it does
1274- /// Checks for using `x.get(x.len() - 1)` instead of
1274+ /// Checks for usage of `x.get(x.len() - 1)` instead of
12751275 /// `x.last()`.
12761276 ///
12771277 /// ### Why is this bad?
@@ -1304,7 +1304,7 @@ declare_clippy_lint! {
13041304
13051305declare_clippy_lint ! {
13061306 /// ### What it does
1307- /// Checks for use of `.get().unwrap()` (or
1307+ /// Checks for usage of `.get().unwrap()` (or
13081308 /// `.get_mut().unwrap`) on a standard library type which implements `Index`
13091309 ///
13101310 /// ### Why is this bad?
@@ -1475,7 +1475,7 @@ declare_clippy_lint! {
14751475
14761476declare_clippy_lint ! {
14771477 /// ### What it does
1478- /// Checks for using `fold` when a more succinct alternative exists.
1478+ /// Checks for usage of `fold` when a more succinct alternative exists.
14791479 /// Specifically, this checks for `fold`s which could be replaced by `any`, `all`,
14801480 /// `sum` or `product`.
14811481 ///
@@ -2161,7 +2161,7 @@ declare_clippy_lint! {
21612161
21622162declare_clippy_lint ! {
21632163 /// ### What it does
2164- /// Checks for usages of `str::splitn(2, _)`
2164+ /// Checks for usage of `str::splitn(2, _)`
21652165 ///
21662166 /// ### Why is this bad?
21672167 /// `split_once` is both clearer in intent and slightly more efficient.
@@ -2197,7 +2197,7 @@ declare_clippy_lint! {
21972197
21982198declare_clippy_lint ! {
21992199 /// ### What it does
2200- /// Checks for usages of `str::splitn` (or `str::rsplitn`) where using `str::split` would be the same.
2200+ /// Checks for usage of `str::splitn` (or `str::rsplitn`) where using `str::split` would be the same.
22012201 /// ### Why is this bad?
22022202 /// The function `split` is simpler and there is no performance difference in these cases, considering
22032203 /// that both functions return a lazy iterator.
@@ -2251,7 +2251,7 @@ declare_clippy_lint! {
22512251
22522252declare_clippy_lint ! {
22532253 /// ### What it does
2254- /// Checks for use of `.collect::<Vec<String>>().join("")` on iterators.
2254+ /// Checks for usage of `.collect::<Vec<String>>().join("")` on iterators.
22552255 ///
22562256 /// ### Why is this bad?
22572257 /// `.collect::<String>()` is more concise and might be more performant
@@ -2377,7 +2377,7 @@ declare_clippy_lint! {
23772377
23782378declare_clippy_lint ! {
23792379 /// ### What it does
2380- /// Checks for usages of `.then_some(..).unwrap_or(..)`
2380+ /// Checks for usage of `.then_some(..).unwrap_or(..)`
23812381 ///
23822382 /// ### Why is this bad?
23832383 /// This can be written more clearly with `if .. else ..`
@@ -2553,7 +2553,7 @@ declare_clippy_lint! {
25532553
25542554declare_clippy_lint ! {
25552555 /// ### What it does
2556- /// Checks for using `x.get(0)` instead of
2556+ /// Checks for usage of `x.get(0)` instead of
25572557 /// `x.first()`.
25582558 ///
25592559 /// ### Why is this bad?
@@ -2957,7 +2957,7 @@ declare_clippy_lint! {
29572957
29582958declare_clippy_lint ! {
29592959 /// ### What it does
2960- /// Detects uses of `Vec::sort_by` passing in a closure
2960+ /// Checks for usage of `Vec::sort_by` passing in a closure
29612961 /// which compares the two arguments, either directly or indirectly.
29622962 ///
29632963 /// ### Why is this bad?
@@ -3013,7 +3013,7 @@ declare_clippy_lint! {
30133013
30143014declare_clippy_lint ! {
30153015 /// ### What it does
3016- /// Checks for use of File::read_to_end and File::read_to_string.
3016+ /// Checks for usage of File::read_to_end and File::read_to_string.
30173017 ///
30183018 /// ### Why is this bad?
30193019 /// `fs::{read, read_to_string}` provide the same functionality when `buf` is empty with fewer imports and no intermediate values.
0 commit comments