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
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
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`.
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
`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
Rust 1.88 introduces the `dangerous_implicit_autorefs` lint which warns
about using implicit autorefs on a place obtained from a raw pointer, as
this may create aliasing issues.
Prevent `clippy::needless_borrow` from triggering in this case, by
disabling the lint when taking a reference on a raw pointer dereference.
There might be a better way for doing this in the long run with a finer
way of distinguish the problematic cases, but this will prevent Clippy
from contradicting the compiler in the meantime.
Fixesrust-lang/rust-clippy#14743
changelog: [`needless_borrow`]: do not contradict the compiler's
`dangerous_implicit_autorefs` lint even though the refererences are not
mandatory
@rustbot label +beta-nominated
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
- [Beta nomination for
1.88](https://github.com/rust-lang/rust-clippy/pull/14810#issuecomment-2883753957)
by [samueltardieu](https://github.com/samueltardieu)
Generated by triagebot, see
[help](https://forge.rust-lang.org/triagebot/note.html) for how to add
more
<!--
TRIAGEBOT_SUMMARY_DATA_START$${"entries_by_url":{"https://github.com/rust-lang/rust-clippy/pull/14810#issuecomment-2883753957":{"title":"Beta
nomination for
1.88","comment_url":"https://github.com/rust-lang/rust-clippy/pull/14810#issuecomment-2883753957","author":"samueltardieu"}}}$$TRIAGEBOT_SUMMARY_DATA_END
-->
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
`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.
Rust 1.88 introduces the `dangerous_implicit_autorefs` lint which warns
about using implicit autorefs on a place obtained from a raw pointer,
as this may create aliasing issues.
Prevent `clippy::needless_borrow` from triggering in this case,
by disabling the lint when taking a reference on a raw pointer
dereference. There might be a better way for doing this in the long run
with a finer way of distinguish the problematic cases, but this will
prevent Clippy from contradicting the compiler in the meantime.
Turns out that `doc_markdown` uses a non-cheap rustdoc function to
convert from markdown ranges into source spans. And it was using it a
lot (about once every 17 lines of documentation on `tokio`, which ends
up being about 2000 times).
This ended up being about 18% of the total Clippy runtime as discovered
by lintcheck --perf in docs-heavy crates. This PR optimizes one of the
cases in which Clippy calls the function, and a future PR once
pulldown-cmark/pulldown-cmark#1034 is merged will be opened. This PR
lands the use of the function into the single-digit zone.
Note that not all crates were affected by this crate equally, those with
more docs are affected far more than those light ones.
changelog:[`clippy::doc_markdown`] has been optimized by 50%
This stops using `cargo fmt` and instead calls rustfmt directly with the
list of all files.
All `cargo fmt` does is find the crate roots and passes the edition from
`cargo.toml`. Since the edition is set in `rustfmt.toml` for the test
files and we're already iterating through all the files this is not
needed.
`--skip-children` is used since we already pass all the files, so the
automatic detection isn't buying us anything other than running slower.
~Second commit~ (part of the first commit now) is a change to only use
the `ignore` option in `rustfmt.toml` rather than having a way in `cargo
dev fmt` to ignore files.
r? @samueltardieu
changelog: none
Fixes
https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Ambiguous.20default.20value.20for.20.60trivial-copy-size-limit.60
The current situation is
| Target width | `trivial-copy-size-limit`|
|--------|--------|
| 8-bit | 2 |
| 16-bit | 4 |
| 32-bit | 8 |
| 64-bit | 8 |
~~Since practically speaking it's almost always 8, let's go with that as
the unconditional default to make it easier to understand~~
Now defaults to `target_pointer_width`
changelog: [`trivial-copy-size-limit`] now also defaults to the size of
a target pointer (unchanged for 64-bit targets)
The first commit fixesrust-lang/rust-clippy#14802: when a slice is
directly present, it must be dereferenced (instead of referenced -1
times) before being passed to `mem::size_of_val()`.
The second commit triggers the lint in a `const` contact when MSRV ≥
1.85.
changelog: [`manual_slice_size_computation`]: fix ICE in suggestion to
efficiently compute the size of a slice, and trigger the lint in `const`
context as well
The `explicit_into_iter_loop`, `explicit_iter_loop` and `iter_next_loop`
will now:
- trigger only when the triggering expression is not located into macro
code;
- properly expose code rewrite proposal with code coming from the root
context.
changelog: [`explicit_into_iter_loop`, `explicit_iter_loop`,
`iter_next_loop`]: behave in macro context
Fixesrust-lang/rust-clippy#14630
Fixesrust-lang/rust-clippy#14750 by reducing the lint span for
needless_return.
changelog: [`needless_return`]: Lint span no longer wraps to previous
line
If a type is incomplete, for example if generic parameters are not
available yet, although they are not escaping, its layout may not be
computable. Calling `TyCtxt::layout_of()` would create a delayed bug in
the compiler.
changelog: [`zero_sized_map_values`]: fix ICE
Fixesrust-lang/rust-clippy#14822
r? @Jarcho
If a type is incomplete, for example if generic parameters are not
available yet, although they are not escaping, its layout may not
be computable. Calling `TyCtxt::layout_of()` would create a delayed bug
in the compiler.
The `explicit_into_iter_loop`, `explicit_iter_loop` and `iter_next_loop`
will now:
- trigger only when the triggering expression is not located into macro
code;
- properly expose code rewrite proposal with code coming from the root
context.
A `return` in an expression makes it divergent and cannot be removed
blindly. While this stripping might have been introduced as a way to
catch more cases, it was improperly used, and no tests exhibit a failure
when this special handling is removed.
changelog: [`needless_match`]: do not strip `return` as it might make
the `if let` or `match` divergent in some cases
Fixesrust-lang/rust-clippy#14754
Fixes#13793.
Interestingly enough, to actually check that the macro call has at least
two arguments, we need to use the rust lexer after getting the original
source code snippet.
changelog: Add new `useless_concat` lint
