The first commit fixes#14164 by making sure that temporaries with
non-static references are also looked for in expressions coming from
expansion. The shortcut that was done skipped those parts and reported
an absence of short-lived temporaries, which was incorrect.
The second commit distinguishes between edition 2024 and earlier ones.
Starting from edition 2024, the problematic drop order has been fixed,
and block variables, which might be referenced in a block expression,
are freed after the block expression itself. This allows more
`let_and_return` cases to be reported starting with edition 2024,
whereas in earlier editions an intermediary variable was necessary to
reorder the drops.
Incidentally, since Clippy is compiled in edition 2024 mode, the second
commit has led to a fix in
`clippy_lints/src/matches/significant_drop_in_scrutinee.rs`.
changelog: [`let_and_return`]: lint more cases in edition 2024, and fix
a false positive involving short-lived block temporary variables in
earlier editions.
Checks for functions with method calls to `.map(_)` on an arg of type
`Option` as the outermost expression.
Fixes#774
```
changelog: [`single_option_map`]: Checks for functions with method calls to `.map(_)` on an arg of type `Option` as the outermost expression.
```
One cannot avoid descending into expansion results when looking for
non-static references, or there is a risk of false negative which would
then trigger the `let_and_return` lint.
fixes: #12659
[`manual_map`] and [`manual_filter`] shares the same check logic, but
this issue doesn't seems like it could affect `manual_filter` (?)
---
changelog: make [`manual_map`] ignore types that contain `dyn`
An `if … { … } else { … }` used as the left operand of a binary
expression requires parentheses to be parsed as an expression.
Fix#11141
changelog: [`obfuscated_if_else`]: fix bug in suggestion by issuing
required parentheses around the left side of a binary expression
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`.
Removing the `.as_ref()` or `.as_mut()` as the top-level expression in a
closure may change the type of the result. In this case, it may be
better not to lint rather than proposing a fix that would not work.
changelog: [`useless_asref`]: do not remove the `.as_ref()` or
`.as_mut()` call if this would change the type of the enclosing closure
Fix#14088
By assuming that a recursive type is normalizable within the deeper
calls to `is_normalizable_helper()`, more cases can be handled by this
function.
In order to fix stack overflows, a recursion limit has also been added
for recursive generic type instantiations.
Fix#9798Fix#10508Fix#11915
changelog: [`large_enum_variant`]: more precise detection of variants
with large size differences
Proposing to replace
```rust
let mut x = PathBuf::from("/foo");
x.push("/bar");
```
by
```rust
let mut x = PathBuf::from("/foo");
x.push("bar");
```
changes the content of `x` (`/bar` ⇒ `/foo/bar`). This is not equivalent
and should not be `MachineApplicable`, even if the original code is
suspicious.
changelog: none
Fix the version of `doc_overindented_list_items`. It actually will be in
1.86.0, not 1.80.0.
(https://github.com/rust-lang/rust/pull/136209 has a milestone of
1.86.0)
changelog: none
- `reindent_multiline()` always returns the result of
`reindent_multiline_inner()` which returns a `String`. Make
`reindent_multiline()` return a `String` as well, instead of a
systematically owned `Cow<'_, str>`.
- There is no reason for `reindent_multiline()` to force a caller to
build a `Cow<'_, str>` instead of passing a `&str` directly, especially
considering that a `String` will always be returned.
Also, both the input parameter and return value (of type `Cow<'_, str>`)
shared the same (elided) lifetime for no reason: this worked only
because the result was always the `Cow::Owned` variant which is
compatible with any lifetime.
As a consequence, the signature changes from:
```rust
fn reindent_multiline(s: Cow<'_, str>, …) -> Cow<'_, str> { … }
```
to
```rust
fn reindent_multiline(s: &str, …) -> String { … }
```
changelog: none
`MachineApplicable` is appropriate for the applicability of this lint.
changelog: [`if_then_some_else_none`]: change the applicability to
`MachineApplicable`
Labeled blocks cannot be used as-is in the "then" or "else" part of an
`if` expression. They must be enclosed in an anonymous block.
Fix#14099
changelog: [`match_bool`]: fix suggestion when the rewritten block has a
label
fixes#12407
I think it is meaningful to emit a warning even if the span is in a
macro.
changelog: [`manual_async_fn`]: don't emit suggestion inside macro
Counting in bytes for a pointer to `u8` is legitimate and must not
trigger the lint. Also, this prevents linting the
`{std,core}::ptr::write_bytes` as it manipulates bytes.
Fix#6590
changelog: [`size_of_in_element_count`]: do not lint if the pointee type
is `u8`
