For example, the `Duration` type from the standard library was only
introduced in Rust 1.3.0.
changelog: [`incompatible_msrv`]: recognize types exceeding MSRV as well
r? Jarcho @rustbot label +C-bug +I-false-negative
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).
In Rust 1.88, the `pin!()` macro uses `unsafe` and triggers
`unsafe_derive_deserialize`.
Fixesrust-lang/rust-clippy#15120
changelog: [`unsafe_derive_deserialize`]: do not trigger because of the
standard library's `pin!()` macro
Fixesrust-lang/rust-clippy#15249
For the builtin rustc, it should return "dev" as the release channel.
Clippy tests pass with this patch in both the Clippy standalone
repository and from within the compiler repository.
changelog: none
This removes preserved spaces after lint name, marginally reducing page
size.
Changing `~}}` into `-}}` will break things: lint name will touch copy
buttons on it's right side.
cc @GuillaumeGomez as one who touched this last time
changelog: none
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
Update `manual_is_variant_and` documentation to include equality
comparison patterns
This commit updates the documentation for the `manual_is_variant_and`
lint to include all linted cases. Previously, the documentation only
mentioned the `.map(f).unwrap_or_default()` pattern, but the lint also
catches equality comparison patterns like `option.map(f) == Some(true)`
and `result.map(f) == Ok(true)`.
changelog: [`manual_is_variant_and`]: Update documentation to include
equality comparison patterns
fixesrust-lang/rust-clippy#15217
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
Before this, you had to guess how to fix a `{:?}` formatting argument. I
have happened to guess `{:?var}` in the past, got frustrated, and
disabled the lint. This additional example would have saved me a bit of
trouble.
changelog: [`uninlined_format_args`]: added an example of how to fix a
`{:?}` parameter.
Follow-up of https://github.com/rust-lang/rust-clippy/pull/15208.
Removed some unneeded wrappings and shortened some CSS class name.
The diff is big because of one indent level getting removed. :-/
Before this PR: 1751301
With this PR: 1663634
Reduction: -5%
r? @samueltardieu
changelog: Reduce page size and number of DOM elements on clippy lints
page
<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
