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
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! ❤️
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.
This PR fixes two vulnerabilities in our CI, found with
[zizmor](https://github.com/woodruffw/zizmor). One could be exploited by
someone with tag-pushing permissions to execute arbitrary code in our CI
(see`deploy.yml`). The second vulnerability would expose our tokens to a
supply chain attack via a `build.rs` in one of the dependencies (See the
rest of the files, and https://github.com/actions/checkout/issues/485)
Pre-reviewed by @flip1995 in our DMs.
changelog:none
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.
I [recently realized that `.last()` might not call `next_back()` when it
is
available](https://qsantos.fr/2025/01/01/rust-gotcha-last-on-doubleendediterator/).
Although the implementor could make sure to implement `last()` to do so,
this is not what will happen by default. As a result, I think it is
useful to add a lint to promote using `.next_back()` over `.last()` on
`DoubleEndedIterator`.
If this is merged, we might want to close #1822.
changelog: [`double_ended_iterator_last`]: Add lint for calling
`Iterator::last()` on `DoubleEndedIterator`
close#13781
The `slow_vector_initialization` lint currently only suggests using the
`vec!` macro with size, but it does not suggest removing the `resize`
method call.
changelog: [`slow_vector_initialization`]: improve
`slow_vector_initialization` suggestion
