We could do with a way to make matching on the `assert_*` macro kind
easier, this came up a bunch here. I'll take a look at that as a follow
up
changelog: none
changelog: [`unwrap_used`, `expect_used`]: lint even when the receiver
is a macro expansion result
This also paves the way for expanding more method call lints to expanded
receivers or arguments.
Fixesrust-lang/rust-clippy#13455
Closes#9191Closes#14444Closes#8055
Adds a new helper to partly check for side effects by recursively
checking if the iterator type contains closures with mutable captures.
changelog: [`double_ended_iterator_last`] fix FP when iter has side
effects
changelog: [`needless_collect`] fix lint not consider side effects
This lint detects inefficient or useless `{std,core}::mem::swap()` calls
such as:
```rust
// Should be `a = temp();`
swap(&mut a, &mut temp());
// Should be `*b = temp();`
swap(b, &mut temp());
// Should be `temp1(); temp2();` if we want to keep the side effects
swap(&mut temp1(), &mut temp2());
```
It also takes care of using a form appropriate for a `()` context if
`swap()` is part of a larger expression (don't ask me why this wouldn't
happen, I have no idea), by suggesting `{ x = y; }` (statement in block)
or `{std,core}::mem::drop((temp1(), temp2())`.
changelog: [`swap_with_temporary`]: new lint
Close#1968
To accurately reflect that RPITIT assoc items don't have a name. This
avoids the use of `kw::Empty` to mean "no name", which is error prone.
Helps with #137978.
`hir::AssocItem` currently has a boolean `fn_has_self_parameter` field,
which is misplaced, because it's only relevant for associated fns, not
for associated consts or types. This commit moves it (and renames it) to
the `AssocKind::Fn` variant, where it belongs.
This requires introducing a new C-style enum, `AssocTag`, which is like
`AssocKind` but without the fields. This is because `AssocKind` values
are passed to various functions like `find_by_ident_and_kind` to
indicate what kind of associated item should be searched for, and having
to specify `has_self` isn't relevant there.
New methods:
- Predicates `AssocItem::is_fn` and `AssocItem::is_method`.
- `AssocItem::as_tag` which converts `AssocItem::kind` to `AssocTag`.
Removed `find_by_name_and_kinds`, which is unused.
`AssocItem::descr` can now distinguish between methods and associated
functions, which slightly improves some error messages.
Instead of looking for angle brackets in the source code, use the HIR
and Ty interfaces to either copy the original type, or complete it with
`_` placeholders if all type and const generic arguments are inferred.
It bugs me when variables of type `Ident` are called `name`. It leads to
silly things like `name.name`. `Ident` variables should be called
`ident`, and `name` should be used for variables of type `Symbol`.
This commit improves things by by doing `s/name/ident/` on a bunch of
`Ident` variables. Not all of them, but a decent chunk.
These method chains can be expressed concisely with `if` / `else`.
changelog: [`obfuscated_if_else`]: support `then().unwrap_or_default()`
and `then_some().unwrap_or_default()`
Until `if let` chains are stabilized, we do not collapse them together
or with other `if` expressions unless the `let_chains` feature is
enabled. This is the case for example in Clippy sources.
This was made possible by converting the `collapsible_if` to a late lint
to get access to the set of enabled features. This allows this PR to
supersede #14455 and no longer require an additional configuration
option.
The three commits are, in order:
- a conversion of the existing early lint to a late lint, with no new
feature or tests changes
- the addition of the `let_chains` feature detection and action, and
tests
- the application of the enhanced lint to Clippy sources (136 files
modified)
changelog: [`collapsible_if`]: recognize the rust compiler `let_chains`
feature
r? @flip1995
The `unnecessary_filter_map` and `unnecessary_find_map` lints were
making partial suggestions, proposing to replace the whole expression by
only the method name, or a subexpression which contained explicit
placeholders.
Since even `MaybeIncorrect` suggestions must generate code that
compiles, this changes those lints to recommandation lints with no
code suggestion.
Closes#11617Closes#14368
Clippy gives wrong suggestions when the filter and then cannot be put
into closure directly. Since trying to transform these can be too
complicated, Clippy will simply warn but don't try to fix.
changelog: [`filter_map_bool_then`]: fix wrong suggestions when the
closure cannot be decompose directly
