Commit 9ef6e2199c introduced a check to
ensure that Clippy doesn't consider a lifetime present in an explicit
self type as being the default for an elided output lifetime. For
example, elision did not work in the case like:
```rust
fn func(self: &Rc<Self>, &str) -> &str { … }
```
Since Rust 1.81.0, the lifetime in the self type is now considered
the default for elision. Elision should then be suggested when
appropriate.
Some widely used crates, such as `pin-project-lite`, make use of a
`pub(crate)` construct in a private module inside a public macro. This
makes unrelated project trigger the lint.
There is also an unfortunate situation for Clippy itself: when a new
version of `pin-project-lite` or similar lint-trigerring crates is
released, those lints which can be found in hundreds of occurrences in
dependent crates will change, and appear as diffs in unrelated Clippy PR
because the base lintcheck run will be cached with the ancient release
of the crates. We currently have the situation
[here](https://github.com/rust-lang/rust-clippy/actions/runs/12635410895?pr=13851#user-content-redundant-pub-crate-removed),
which 219 lints removed and 219 lints added because of a
`pin-project-lite` version change between runs, and the fact that
`redundant_pub_crate` triggers on external macros.
Also:
- Fix#10636
- Fix#12213
changelog: [`redundant_pub_crate`]: do not trigger on external macros
It claims to be in 1.83 but in fact will not be until 1.85.
Evidence: <https://github.com/rust-lang/rust/pull/134788> is where it
was merged into rust-lang/rust, and has a milestone of 1.85.
changelog: none
changelog: [`manual_ok_err`]: new lint
Detect manual implementations of `.ok()` or `.err()`, as in
```rust
let a = match func() {
Ok(v) => Some(v),
Err(_) => None,
};
let b = if let Err(v) = func() {
Some(v)
} else {
None
};
```
which can be replaced by
```rust
let a = func().ok();
let b = func().err();
```
This pattern was detected in the wild in the Rust reimplementation of
coreutils:
https://github.com/uutils/coreutils/pull/6886#pullrequestreview-2465160137
Rerunning the PR checks when a PR is synchronized (new commits added, or
force-pushed) seems to remove the changelog checks from the UI while
keeping the PR mergeable from the maintainer's interface.
This PR reruns the cheap changelog check when a PR is synchronized.
changelog: none
r? @flip1995
Rerunning the PR checks when a PR is synchronized (new commits added, or
force-pushed) seems to remove the changelog checks from the UI while
keeping the PR mergeable from the maintainer's interface.
This PR reruns the cheap changelog check when a PR is synchronized.
This removes the last call to `LateContext::match_def_path()` in
Clippy's code. The `LateContext::match_def_path()` in the compiler
sources was only kept for Clippy's usage.
Once this PR is merged and after the rustup, I will submit one to remove
`LateContext::match_def_path()` from the compiler.
changelog: none
r? @flip1995
Checking it only in the merge queue leads to deferred failures once the
decision to merge has been taken already.
- [X] Testing first without changelog line
- [x] Now that that has failed, adding the changelog line and
force-pushing
changelog: none
The code should not attempt to obtain a snippet by capping the function
signature span with its identifier span without checking that they are
in the same context.
This is the only instance I could identify where placeholders were used
instead of the real snippet when running the CI lintcheck. Moreover, the
placeholders were not even used, as they snippet was obtained
prematurely.
Found in the context of #13941
changelog: none
Some lifetimes in function return types are not bound to concrete
content and can be set arbitrarily. Clippy should not propose to replace
them by the default `'_` lifetime if such a lifetime cannot be
determined unambigously.
I added a field to the `LifetimeChecker` and `Usage` to flag lifetimes
that cannot be replaced by default ones, but it feels a bit hacky.
Fix#13923
changelog: [`needless_lifetimes`]: remove false positives by checking
that lifetimes can indeed be elided
The code should not attempt to obtain a snippet by capping the
function signature span with its identifier span without checking that
they are in the same context.
I ran Clippy on some projects after upgrading to 1.84, which found a
[needless use of
`as_bytes()`](https://github.com/rust-lang/rust-clippy/pull/13437). It
made me notice that the code was also using `bytes()` needlessly in
other places. This PR improves on the `as_bytes()` lint to also lint
`bytes()`.
----
changelog: none
It claims to be in 1.83 but in fact will not be until 1.85.
Evidence: <https://github.com/rust-lang/rust/pull/134788> is where it was merged into rust-lang/rust, and has a milestone of 1.85.
Fixes#13913 .
changelog: [`manual_is_ascii_check`]: fix type suggestions for
references
Previously it only derived `char` and `u8` types, now it should always
annotate the lambda parameter with the correct type (e.g. `&char`).
I'm quite new to Rust and this is my first contact with clippy, so I'm
open for suggetions :)
Some lifetimes in function return types are not bound to concrete
content and can be set arbitrarily. Clippy should not propose to replace
them by the default `'_` lifetime if such a lifetime cannot be
determined unambigously.
Removing `.map(identity)` may result in invalid code if the receiver of
`map()` is an immutable binding, and the result of `map()` is used as
the receiver of a method call expecting a mutable reference.
Fix#13904
changelog: [`map_identity`]: do not lint if this would cause mandatory
mutability to be lost
When the expression is transformed into an equality, parentheses are
needed only if the resulting equality is used:
- as a receiver in a method call
- as part of a binary or unary expression
- as part of a cast
In other cases, which will be the majority, no parentheses are required.
This makes the lint suggestions cleaner.
changelog: `none`
`rustup show active-toolchain` will no longer install the default
toolchain starting from Rustup 1.28.0, and `rustup toolchain install`
without extra arguments is not supported in Rustup pre-1.28.0.
The Rustup change and proposed solution is described in
<https://internals.rust-lang.org/t/seeking-beta-testers-for-rustup-v1-28-0/22060>.
changelog: none
Fixes https://github.com/rust-lang/rust-clippy/issues/8528.
Similar to #13911, if there are code comments, we don't want to remove
them automatically.
changelog: Don't emit machine applicable `map_flatten` lint if there are
code comments
r? @xFrednet
Even its documentation says so. According to the documentation, it might
either be a "suspicious" or a "perf" lint.
changelog: [`redundant_locals`]: Reclassify as "suspicious" lint.
Roses are red,
Violets are blue,
Happy new year,
full of happiness and cheer!
---
### The cat of this release is lizzy nominated by @jdonszelmann:
<img height=700
src="https://github.com/user-attachments/assets/612834d0-d584-4bf3-b11e-3564456c10ee"
alt="The cats of this Clippy release" />
Cats for the next release can be nominated in the comments :D
---
I've also updated the template to include the text I usually use for
moves, renames, or new lints.
changelog: none
---
That's it happy new year, kings, queens, and all other royalty! ❤️
This removes the last call to `LateContext::match_def_path()` in
Clippy's code. The `LateContext::match_def_path()` in the compiler
sources was only kept for Clippy's usage.
Fixes#13692.
If the `vec!` macro call contains comments, we should not provide
suggestions and let users handle it however they see fit.
changelog: Only emit `useless_vec` suggestion if the macro does not
contain code comments
`rustup show active-toolchain` will no longer install the default
toolchain starting from Rustup 1.28.0, and `rustup toolchain install`
without extra arguments is not supported in Rustup pre-1.28.0.
fixes: #4077
Continuation of #11546. r? @y21 if you don't mind?
changelog: [`needless_continue`] lint if the last stmt in loop is
`continue` recurisvely
turn rustc_box into an intrinsic
I am not entirely sure why this was made a special magic attribute, but an intrinsic seems like a more natural way to add magic expressions to the language.
