When determining when a function or method can be called from a `const`
context, the determination must be made on the instance, not on the
declaration. This makes a difference, for example, with `const_trait`
traits whose implementations may or may not be `const`.
changelog: [`missing_const_for_fn`]: when checking if a function or
method can be called from a `const` context, look at the concrete
implementation rather than at the trait definition
Fixesrust-lang/rust-clippy#14658
r? @Jarcho
If an early return is found under the HIR local declaration node but
before the child process is created, it should not trigger the lint
because the child process has not yet been created.
changelog: [`zombie_process`]: do not complain about early early returns
Fixesrust-lang/rust-clippy#14911
This test checks that all symbols defined in Clippy's `sym.rs` file are
used in Clippy. Otherwise, it will fail with a list of symbols which are
unused.
This test only runs when the `internal` feature is set, to allow
developers to temporarily define new, yet unused symbols without failing
the tests. Also, it will not run as part of the compiler test suite, as
an extra symbol should never be seen as a fatal problem in the compiler
repo.
changelog: none
`clippy_lints::casts::utils::int_ty_to_nbits` used to return `0` to
indicate that the argument was not an integral type. It is more
idiomatic to use `Option<u64>` as a return type.
Also, I've added a few `FIXME:` at places where only `f32` and `f64` are
considered, as we now have `f16` and `f128` to deal with.
changelog: none
Looks for `TryFrom` implementations with uninhabited error types and
suggests to implement `From` instead.
Fixesrust-lang/rust-clippy#2144
---
changelog: Add [`infallible_try_from`] lint
`clippy_lints::casts::utils::int_ty_to_nbits` used to return `0` to
indicate that the argument was not an integral type. It is more
idiomatic to use `Option<u64>` as a return type.
In order to be consistent with our documentation, deprecated lints
should not be counted when displaying the total number of lints on the
[web site](https://rust-lang.github.io/rust-clippy/master/index.html).
For example, as of 2025-06-01, there are 784 non-deprecated lints which
are referred to as "over 750 lints" in the documentation, but the web
site displays "Total number: 799". When one new lint will be added,
there will be a discrepancy ("over 750 lints" vs. "Total number: 800")
if this is not fixed.
changelog: none
r? @llogiq
In order to be consistent with our documentation, deprecated lints
should not be counted when displaying the total number of lints on the
[web site](https://rust-lang.github.io/rust-clippy/master/index.html).
For example, as of 2025-06-01, there are 784 non-deprecated lints which
are referred to as "over 750 lints" in the documentation, but the web site
displays "Total number: 799". When one new lint will be added, there
will be a discrepancy ("over 750 lints" vs. "Total number: 800") if this
is not fixed.
I read a blog post about kernel security, and how various features might
get lost while porting to Rust. In kernel C, they have some guardrails
against divulging pointers. An easy way to replicate that in Rust is a
lint for pointer formatting. So that's what this lint does.
---
changelog: new [`pointer_format`] lint
When determining when a function or method can be called from a `const`
context, the determination must be made on the instance, not on the
declaration. This makes a difference, for example, with `const_trait`
traits whose implementations may or may not be `const`.
`is_trait_method` is not even used in this codeblock, whereas
`implements_trait` is used but not imported
(not sure if this is _actually_ a "changelog: none", since the
documentation is at least contributor-facing)
changelog: none
Reorder `ast::ItemKind::{Struct,Enum,Union}` fields.
So they match the order of the parts in the source code, e.g.:
```
struct Foo<T, U> { t: T, u: U }
<-><----> <------------>
/ | \
ident generics variant_data
```
r? `@fee1-dead`
If an early return is found under the HIR local declaration node but
before the child process is created, it should not trigger the lint
because the child process has not yet been created.
Placeholders are still given for the content of the whole block.
However, if the result of the original `if let` or `match` expression
was assigned, the assignment is reflected in the suggestion.
No-op assignments (`let x = x;`) are skipped though, unless they contain
an explicit type which might help the compiler (`let x: u32 = x;` is
kept).
Closesrust-lang/rust-clippy#362
changelog: [`while_let_loop`]: include `let` assignment in suggestion
This lint was previously written very clumsily, not short-circuiting and
doing a lot of unnecessary work.
Now it makes sure to do the cheaper functions earlier and in general, is
just smarter.
(I specifically focused on minimizing binder instantiation
Sadly, I'm not finding any relevant result in a benchmark. Still with
the LLVM coverage instruments, the expensive bits are called lots of
less times (The binder instantiation that I care about is reduced from
95k to 10k throughout our test suite).
changelog:[`unit_return_expecting_ord`]: Optimize the lint
This lint was previously written very clumsily, not
shortcircuiting and doing a lot of unnecessary work.
Now it makes sure to do the cheaper functions earlier
and in general, just be smarter.
(I specifically focused on minimizing binder instantiation)
Also, avoid allocating unnecessarily
`if` expressions don't necessarily contain a block in the `else` part in
the presence of an `else if`. The `else` part, if present, must be
handled as a regular expression, not necessarily as a block expression.
Found while applying Clippy to triagebot and looking at the result. This
also found an issue in Clippy itself.
changelog: [`needless_return`]: look inside `else if` parts as well
So they match the order of the parts in the source code, e.g.:
```
struct Foo<T, U> { t: T, u: U }
<-><----> <------------>
/ | \
ident generics variant_data
```
