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
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
Sometimes, in doc comments, there are 3 spaces + 1 instead of 4 spaces + 1.
To make it coherent with the rest of the clippy codebase, I `fd -t f -X sed -E -i 's,/// (\S),/// \1,g'` and manually verified and fixed the relevant part of code that had bad indentation.
Continuing the work from #137350.
Removes the unused methods: `expect_variant`, `expect_field`,
`expect_foreign_item`.
Every method gains a `hir_` prefix.
These method chains can be expressed concisely with `if`/`else`.
changelog: [`obfuscated_if_else`]: support `then().unwrap_or_else()` and
`then_some().unwrap_or_else()`
The end goal is to eliminate `Map` altogether.
I added a `hir_` prefix to all of them, that seemed simplest. The
exceptions are `module_items` which became `hir_module_free_items` because
there was already a `hir_module_items`, and `items` which became
`hir_free_items` for consistency with `hir_module_free_items`.
By default, do not lint `.unwrap()` and `.expect(…)` in always const
contexts, as a failure would be detected at compile time anyway.
New options `allow_expect_in_consts` and `allow_unwrap_in_consts`,
defaulting to `true`, can be turned unset to still lint in always const
contexts.
While extending the `option_map_or_err_ok` lint (warn by default,
"style") to recognize η-expanded forms of `Ok`, as in
```rust
// Should suggest `opt.ok_or("foobar")`
let _ = opt.map_or(Err("foobar"), |x| Ok(x));
```
I discovered that the `manual_ok_or` lint (allow by default, "pedantic")
already covered exactly the cases handled by `option_map_or_err_ok`,
including the one I was adding. Apparently, `option_map_or_err_ok` was
added without realizing that the lint already existed under the
`manual_ok_or` name. As a matter of fact, artifacts of this second lint
were even present in the first lint `stderr` file and went unnoticed for
more than a year.
This PR:
- deprecates `option_map_or_err_ok` with a message saying to use
`manual_ok_or`
- moves `manual_ok_or` from "pedantic" to "style" (the category in which
`option_map_or_err_ok` was)
In addition, I think that this lint, which is short, machine applicable,
and leads to shorter and clearer code with less arguments (`Ok`
disappears) and the removal of one level of call (`Err(x)` is replaced
by `x`), is a reason by itself to be in "style".
changelog: [`option_map_or_err_ok` and `manual_ok_or`]: move
`manual_ok_or` from "pedantic" to "style", and deprecate the redundant
style lint `option_map_or_err_ok`.
`rustc_middle` is a huge crate and it's always good to move stuff out of
it. There are lots of similar methods already on `Span`, so these two
functions, `in_external_macro` and `is_from_async_await`, fit right in.
The diff is big because `in_external_macro` is used a lot by clippy
lints.
part of https://github.com/rust-lang/rust-clippy/issues/9100
The `obfuscated_if_else` lint currently only triggers for the pattern
`.then_some(..).unwrap_or(..)`, but there're other cases where this lint
should be triggered, one of which is `.then(..).unwrap_or(..)`.
changelog: [`obfuscated_if_else`]: trigger lint for the
`.then(..).unwrap_or(..)` pattern as well
`manual_ok_or` covers the same case that were covered by
`option_map_or_err_ok` which is not deprecated. The latter was in the
"style" category. Also, the lint is machine applicable, and leads to
shorter and more readable code, so "style" is appropriate.
The only difference is that the η-expanded form of `Result::Ok()` was
not covered by `option_map_or_err_ok` while it is by `manual_ok_or`, so
the category change may expose some new occurrences.
A multipart suggestion will be used whenever the method call can be
replaced by another one with the first argument removed. It helps place
the new method call in context, especially when it is part of a larger
expression.
This fixes#13995 by applying a suggestion made by @y21.
r? @y21
changelog: [`unnecessary_map_or`]: better representation of suggestions
by placing them in context
A multipart suggestion will be used whenever the method call can be
replaced by another one with the first argument removed. It helps place
the new method call in context, especially when it is part of a larger
expression.
