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 -->
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
This patch series makes heavy use of interned symbols when matching
against known method names:
- the first commit reorders the current list of symbols in
`clippy_utils::sym`
- the second commit adds symbol reordering and order checking to `clippy
dev fmt` / `clippy dev fmt --check`
- the third commit converts many uses of string matching during linting
to symbols matching
The symbols are kept as-is (not rendered as strings) as much as possible
to avoid needing locking the interner as much as possible. Static
strings have been kept when they are only used when emitting a
diagnostic, as there is no benefit in using interned strings for
de-interning them right after.
changelog: none
r? @Alexendoo
Items such as the `declare_tool_lint!()` macro are publicly reexported
from `rustc_lint_defs` to `rustc_session`. Use the latter for
consistency.
changelog: none
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
It is not enough to check if an expression type implements `Drop` to
determine whether it can have a significant side-effect.
Also, add tests for unchecked cases which were explicitly handled in the
code, such as checking for side effect in a `struct`'s fields, or in its
base expression.
Fixrust-lang/rust-clippy#14592
changelog: [`no_effect_underscore_binding`]: do not propose to remove
the assignment of an object if dropping it might indirectly have a
visible side effect
make `rustc_attr_parsing` less dominant in the rustc crate graph
It has/had a glob re-export of `rustc_attr_data_structures`, which is a crate much lower in the graph, and a lot of crates were using it *just* (or *mostly*) for that re-export, while they can rely on `rustc_attr_data_structures` directly.
Previous graph:
Graph with this PR:
The first commit keeps the re-export, and just changes the dependency if possible. The second commit is the "breaking change" which removes the re-export, and "explicitly" adds the `rustc_attr_data_structures` dependency where needed. It also switches over some src/tools/*.
The second commit is actually a lot more involved than I expected. Please let me know if it's a better idea to back it out and just keep the first commit.
