For example, adding `*` in front of `*expression` is best shown as
`**expression` rather than `*(*expression)`.
This is not perfect, as it checks whether the operator is already a
prefix of the expression, but it is better than it was before. For
example, `&`+`&mut x` will get `&&mut x` but `&mut `+`&x` will get `&mut
(&x)` as it did before this change.
changelog: none
Optimize `needless_doctest_main`, make it short-circuit, make sure that
we don't spin up a new compiler on EVERY code block.
---
The old implementation was creating a new compiler, new parser, new
thread, new SessionGlobals, new everything for each code block. No
matter if they actually didn't even contain `fn main()` or anything
relevant.
On callgrind, seems that we're reducing about a 6.7242% de cycle count
(which turns out to be a 38 million instruction difference, great!).
Benchmarked in `bumpalo-3.16.0`. Also on bumpalo we spawn 78 less
threads. This moves `SessionGlobals::new` from the top time-consuming
function by itself in some benchmarks, into one not even in the top 500.
Also, populate the test files.
changelog:[`needless_doctest_main`]: Avoid spawning so many threads in
unnecessary circumstances
The lint will note `the end suggestion probably needs some adjustments
to use the expression result correctly` when the expr's is not unit. So
I extend this note to also appear when the expr is in an assignment.
changelog: [`branches_sharing_code`] fix misleading suggestions when in
assignment
~~I've added a `min_divisor` configuration option, default to 4, to not
trigger on smaller divisibility operations. I would prefer not to lint
`if a & 1 == 0` as `if a.is_multiple_of(2)` by default because the
former is very idiomatic in systems (and embedded) programming.~~
~~A `min_and_mask_size` option, defaulting to 3, sets the default bits
to be and-masked before this lint triggers; that would be `n` in `v &
((1 << n) - 1) == 0`. The form `v % 10 == 0` is always linted.~~
~~This PR will stay in draft mode until the next rustup which will mark
`unsigned_is_multiple_of` stable for Rust 1.87.0, and the feature flags
will be removed.~~
What should its category be? I've used "complexity", but "pedantic"
might be suitable as well.
Closerust-lang/rust-clippy#14289
changelog: [`manual_is_multiple_of`]: new lint
r? ghost
If a function environment contains trait bounds other than `Sized`,
`const` cannot be used before Rust 1.61.
changelog: [`missing_const_for_fn`]: check MSRV before emitting lint on
function containing non-`Sized` trait bounds
Fixesrust-lang/rust-clippy#15079
r? Jarcho
Based on rust-lang/rust-clippy#14633
The end goal here is to split `clippy_lints` into several independent
crates and have the driver call out to each of them to register lints.
`clippy_lints` takes way too long to compile right now.
r? @flip1995
changelog: none
Closesrust-lang/rust-clippy#8244Closesrust-lang/rust-clippy#15041
This feels like a bug with the compiler, because the panic happens when
`Diag` is getting unwinded. However, `drop()` is already called in
`.cancel()` so this should not happen.
In this PR, I find a workaround to just call `emit()`, since the
`DiagCtxt` here is just a `io::sink`, nothing will happen and the panic
just goes away.
changelog: [`needless_doctest_main`] fix panic when doctest is invalid
So this is funny, the query `tcx.module_children` was top 3 in most
time consuming functions in Clippy, it was being called 24384 times in
tokio. "Unacceptable!" I thought. Digging a bit around, turns out that
`clippy::strlen_on_c_strings` was calling for `get_def_path` via
`match_libc_symbol`. This query pretty-prints things and performs some
analysis.
Yes, we were running early lint checks to see if symbols were from
`libc`.
I don't really trust callgrind when it says I've turn 81 billion
instructions
into like 10 million. So I benchmarked this the good ol' "compiling 20
times
without incr" method and it went from 0.31s-0.45s to 0.25s
constistently.
(Profiled, and "benchmarked") on tokio.
What I can get behind is via `strlen_on_c_strings` changing from 31
million instructions into 76k. 🎉🥳
changelog: [`strlen_on_c_strings`]: Optimize it by 99.75%
So this is funny, the query `tcx.module_children` was top 3 in most
time consuming functions in Clippy, it was being called 24384 times in
tokio. "Unacceptable!" I thought. Digging a bit around, turns out that
`clippy::strlen_on_c_strings` was calling for `get_def_path` via
`match_libc_symbol`. This query pretty-prints things and performs some
analysis.
Yes, we were running early lint checks to see if symbols were from `libc`.
I don't really trust callgrind when it says I've turn 81 billion instructions
into like 10 million. So I benchmarked this the good ol' "compiling 20 times
without incr" method and it went from 0.31s-0.45s to 0.25s constistently.
(Profiled, and "benchmarked") on tokio.
Closesrust-lang/rust-clippy#14692
The suggestion of `manual_flatten` does not includes the replacement of
`if let` so far despite of `.flatten()` suggestion.
This PR eliminates a redundant `if let`.
changelog: [`manual_flatten`] the suggestion removes `if let`
It doesn't seem to be load bearing for any clippy lints and the rustc
ones that no longer appear behave the same as they would for a `cargo
check`
r? @blyxyas
changelog: none
