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
`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.
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
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
```
One downside to this is that, since the patterns matched against (on the
left) are quite long, it's a bit difficult to see what's even getting
matched. Using `matches!()` could help with that
changelog: none
So, after https://github.com/rust-lang/rust-clippy/pull/14693 was
merged,
this is the continuation. It performs some optimizations on
`Fragments::span`
, makes it so we don't call it so much, and makes a 85.75% decrease
(7.51% -> 1.07%)
in execution samples of `source_span_for_markdown_range` and a 6.39% ->
0.88%
for `core::StrSearcher::new`. Overall a 13.11% icount decrase on
docs-heavy crates.
Benchmarked mainly on `regex-1.10.5`.
@rustbot label +performance-project
This means that currently our heaviest function is
`rustc_middle::Interners::intern_ty`, even
for documentation-heavy crates
Along with rust-lang/rust-clippy#14693, this makes the lint a 7% of what
it was before and makes it so that even in the most doc-heavy of crates
it's not an issue.
changelog:Optimize documentation lints by a further 85%
r? @Jarcho
So, after https://github.com/rust-lang/rust-clippy/pull/14693 was merged,
this is the continuation. It performs some optimizations on `Fragments::span`
, makes it so we don't call it so much, and makes a 85.75% decrease (7.51% -> 10.07%)
in execution samples of `source_span_for_markdown_range` and a 6.39% -> 0.88%
for `core::StrSearcher::new`. Overall a 13.11% icount decrase on docs-heavy crates.
Benchmarked mainly on `regex-1.10.5`.
This means that currently our heaviest function is `rustc_middle::Interners::intern_ty`, even
for documentation-heavy crates
Co-authored-by: Roope Salmi <rpsalmi@gmail.com>
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%
