This PR supersedes #14328 following the [2025-03-18 Clippy meeting
discussion](https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/Meeting.202025-03-18/with/506527762).
It uses a simpler approach than what was proposed initially in #14328
and does not add new options.
First, it documents how `cfg_attr` can be used to change the MSRV
considered by Clippy to trigger the lint. This allows the MSRV to be
feature gated, or to be raised in tests.
Also, the lint stops warning about items which have been explicitly
allowed through a rustc feature. This works even if the feature has been
stabilized since. It allows using an older compiler with some features
turned on, as is done in Rust for Linux. This fixes#14425.
Then, if the lint triggers, and it looks like the code is located below
a `cfg` or `cfg_attr` attribute, an additional note is issued, once, to
indicate that the `clippy::msrv` attribute can be controlled by an
attribute.
Finally, the lint is extended to cover any path, not just method and
function calls. For example, enumeration variants, or constants, were
not MSRV checked. This required replacing two `u32::MAX` by
`u32::max_value()` in MSRV-limited tests.
An extra commit adds a TODO for checking the const stability also, as
this is not done right now.
@Centri3 I'll assign this to you because you were assigned #14328 and
you were the one who nominated the issue for discussion (thanks!), but
of course feel free to reroll!
r? @Centri3
changelog: [`incompatible_msrv`]: better documentation, honor the
`features` attribute, and lint non-function entities as well
To avoid false positives, the `range_plus_one` and `range_minus_one`
lints will restrict themselves to situations where the iterator types
can be easily switched from exclusive to inclusive or vice-versa. This
includes situations where the range is used as an iterator, or is used
for indexing.
On the other hand, assignments of the range to variables, including
automatically typed ones or wildcards, will no longer trigger the lint.
However, the cases where such an assignment would benefit from the lint
are probably rare.
In a second commit, the `range_plus_one` and `range_minus_one` logic are
unified, in order to properly emit parentheses around the suggestion
when needed.
Fixrust-lang/rust-clippy#3307Fixrust-lang/rust-clippy#9908
changelog: [`range_plus_one`, `range_minus_one`]: restrict lint to cases
where it is safe to switch the range type
*Edit:* as a consequence, this led to the removal of three
`#[expect(clippy::range_plus_one)]` in the Clippy sources to avoid those
false positives.
No longer suggests `&[i32]` or `&mut [i32]` instead of `&Vec<i32>` or
`&mut Vec<i32>` (also: `Path` and `PathBuf`, etc.) for the parameter
type when the parameter name starts with an underscore (or, if that does
not start with one, then a local `let` binding in the function body,
pointing to the same value, does) – (Fixesrust-lang/rust-clippy#13489,
fixesrust-lang/rust-clippy#13728)
~changelog: fix false positive: [`ptr_arg`] no longer triggers with
underscore binding to `&mut` argument~
changelog: fix false positive: [`ptr_arg`] no longer triggers with
underscore binding to `&T` or `&mut T` argument
*Edit:* This change has been extended to all references, not just
mutable ones. See [discussion below](#issuecomment-3006386877).
Previously expect_fun_call would too eagerly convert cases like
`foo.expect(if | block | match)` into `foo.unwrap_or_else`.
Additionally, it would also add to_string() even though the argument is
being passed into format!() which can accept a &str. I also discovered
some other cases where this lint would either produce invalid results,
or be triggered unnecessarily:
- Clippy would suggest changing expect to unwrap_or_else even if the
expression inside expect contains a return statement
- opt.expect(const_fn()) no longer triggers the lint
- The lint would always add braces to the closure body, even if the body
of expect is a single expression
- opt.expect({"literal"}) used to get turned into
```opt.unwrap_or_else(|| panic!("{}", {"literal"}.to_string()))```
Fixesrust-lang/rust-clippy#15056
changelog: [`expect_fun_call`]: fix expect_fun_call producing invalid
suggestions
Fix several issues with `manual_is_multiple_of`
- `&a % &b == 0` compiles, but requires dereferencing `b` when replacing
with `a.is_multiple_of(b)`.
- In `a % b == 0`, if type of `a` is not certain, `a.is_multiple_of(b)`
might not be typable.
- In `a % b == 0`, `a` and `b` must be unsigned integers, not any
arbitrary types implementing `Rem` and outputing an integer.
Those fixes have required increasing the precision of type certainty
determination in the two first patches.
Fixesrust-lang/rust-clippy#15203Fixesrust-lang/rust-clippy#15204
changelog: [`manual_is_multiple_of`]: fix various false positive
Fix some cases for `approx_const`:
- When the literal has more digits than significant ones, the string
comparison wasn't working
- When numbers are formatted in a non trivial way (with leading `0`s or
using `_`) the lint now finds those cases
changelog: [`approx_const`]: Fix when used over overly precise literals
and non trivially formatted numerals
Fixesrust-lang/rust-clippy#15194
<strike>blocked on rust-lang/rust-clippy#15073</strike>
Lint method calls inside `map_or` too, so for this, lint will be showed:
```rust
Some(4).map_or("asd".to_string().len() as i32, f);
```
previously it worked only for:
```rust
Some(4).map_or(slow_fun(), f);
```
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=bfcda42a6af446e69bc883a8b45eb13c
Sorry for multiple `or_fun_call` PRs.
changelog: [`or_fun_call`]: lint method calls inside map_or first arg
Closesrust-lang/rust-clippy#15063
----
changelog: [`op_ref`]: fix wrongly showed macro definition in
suggestions
changelog: [`needless_bool_assign`]: fix missing curlies when on else if
When comparing `x.map(func) == Some(bool_lit)`, the value of `bool_lit`
was ignored, despite the fact that its value should determine the value
of the proposed expression.
`func` can be either a closure or a path. For the latter, η-expansion
will be used if needed to invert the result of the function call.
changelog: [`manual_is_variant_and`]: fix inverted suggestions that
could lead to code with different semantics
Fixesrust-lang/rust-clippy#15202
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Beta-nomination](https://github.com/rust-lang/rust-clippy/pull/15206#issuecomment-3034006613)
by [samueltardieu](https://github.com/samueltardieu)
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
Propose to replace `x.map_or(false, |y| y == z)` by `x == Some(z)` only
if `x` is not adjusted. Otherwise, the type of `x` in the comparaison
may not be the expected one, as it may be the product of an auto-deref.
changelog: [`unnecessary_map_or`]: do not propose to replace the
`map_or` call by a comparaison if types wouldn't be correct
Fixesrust-lang/rust-clippy#15180
When comparing `x.map(func) == Some(bool_lit)`, the value of `bool_lit` was
ignored, despite the fact that its value should determine the value of
the proposed expression.
`func` can be either a closure or a path. For the latter, η-expansion
will be used if needed to invert the result of the function call.
<strike>build on top of rust-lang/rust-clippy#15071</strike>
This also adds ability to lint Option/Result::and method. Yes, this is
not `or` method, but uses the same eager/lazy linting logic. Should i
update lint description to list all checked structs/methods?
changelog: [`or_fun_call`]: lint Option/Result::and
The `TyCtxt::hir_get_fn_id_for_return_block()` function was too broad,
as it will return positively even when given part of an expression that
can be used as a return value. A new
`potential_return_of_enclosing_body()` utility function has been made to
represent the fact that an expression might be directly returned from
its enclosing body.
changelog: [`return_and_then`]: prevent false positives in case of a
partially used expression
Fixesrust-lang/rust-clippy#15111Fixesrust-lang/rust-clippy#14927
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Beta-nomination](https://github.com/rust-lang/rust-clippy/pull/15115#issuecomment-2996222332)
by [samueltardieu](https://github.com/samueltardieu)
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
This commit also adds more test cases, which already worked but were
mentioned in the issue.
Fixesrust-lang/rust-clippy#9939
changelog: [`manual_let_else`]: correctly handle binding subpattern with
unused name
Fixes: rust-lang/rust-clippy#14897, rust-lang/rust-clippy#10015
This is not a perfect solution, but it fixes the issue. Happy to discuss
further with the clippy team.
This PR refines check_mul_add to avoid false positives on ambiguous
float types (e.g., f32 vs f64). It improves type detection and ensures
mul_add is only suggested when the type is clear.
Changes:
- Improved detection of ambiguous float types
- Refined mul_add suggestion logic
- Added tests for ambiguous cases
## Example
Before this change, expressions like:
```rust
let x = 1.0; // ambiguous type
let _ = x * 2.0 + 0.5; // could incorrectly suggest mul_add
```
----
changelog: [`suboptimal_flops`]: improve handling of ambiguous float
types in mul_add suggestions
Hi,
I noticed that the lint
[neg_multiply](https://rust-lang.github.io/rust-clippy/master/index.html#neg_multiply)
generates bad code when we call a method on the expression.
Consider `((a.delta - 0.5).abs() * -1.0).total_cmp(&1.0)`. Currently
this would be changed by clippy to `-(a.delta - 0.5).abs()
.total_cmp(&1.0)` - which does not compile because we are trying to
negate an ordering enum - but what we really want is `(-(a.delta -
0.5).abs()).total_cmp(&1.0)`.
This PR fixes this.
changelog: [`neg_multiply`] does not remove parenthesis anymore if a
method is being called on the affected expression
NOTE: This is the first time I am contributing to clippy or the rust
repo in general. So I am not sure whether my approach to fixing this
issue is goo, if there are better solutions or if I missed something.
Thanks & hope you have a good day,
Dario
Fixesrust-lang/rust-clippy#9583
When a closure with no parameters is called immediately after being
defined, clippy can now suggest replacing the entire expression with
just the closure's body.
----
changelog: [`redundant_closure_call`]: add fixes for closures with block
While `expr as T` can be removed as a statement if `expr` has no
side-effect, the `as T` part alone cannot be removed if the type of
`expr` would be ambiguous without the cast.
changelog: [`unnecessary_operation`]: do not remove casts if they are
useful to type the expression
Fixesrust-lang/rust-clippy#15173
