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
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
No breaking changes for clippy in this update (which only impacts the
lint page).
The askama release information is
[here](https://github.com/askama-rs/askama/releases/tag/v0.14.0).
r? @samueltardieu
changelog: update askama version to `0.14.0`
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%
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
