- Now lintcheck perf deletes target directory after benchmarking,
benchmarking with a cache isn't very useful or telling of any
precise outcome.
- Support for benchmarking several times without having to do
a cargo clean. Now we can benchmark a PR and master (or a single
change in the same commit) without having to move the perf.data files
into an external directory.
- Compress perf.data to allow for allowing multiple stacks and
occupy much less space
Introducing a new chapter to the book, known as "Benchmarking Clippy".
It explains the benchmarking capabilities of lintcheck --perf
and gives a concrete example on how benchmark and compare a PR with
master
Turns out I was completely overcomplicating myself,
there was no need for an external tool such as becnhv2
or even the original becnh, we already had the benchmarking
infrastructure right under our noses!
This PR implements a new **lintcheck** option called
--perf, using it as a flag will mean that lintcheck
builds Clippy as a release package and hooks perf to it.
The realization that lintcheck is already 90% of what
a benchmarking tool needs came to me in a dream ☁️
changelog:none
This fixes the buttons that expand/collapse all the lints in the list,
it also makes code block syntax highlighting only happen when the
specific lint enters the viewport since highlighting them all at once
was fairly heavy
There's also a few miscellaneous inline event handler removals
`script.js` and highlightjs are now loaded with `defer` so that the
download can start earlier
Also fixes https://github.com/rust-lang/rust-clippy/issues/14048, we
were calling highlight on the `pre` in `<pre><code>...</code></pre>` but
highlightjs wants us to call it on the `code` element
changelog: none
A `ref` pattern applied to an argument is not ignored. It creates a
reference as expected, but still requires the function to take ownership
of the argument given to it.
Fix#14131
changelog: [`toplevel_ref_arg`]: use a clearer lint message
A `ref` pattern applied to an argument is not ignored. It creates a
reference as expected, but still requires the function to take ownership
of the argument given to it.
Removing the semicolon of the last statement of an expressionless block
may change the block type even if the statement's type is `()`. If the
block type is `!` because of a systematic early return, typing it as
`()` may make it incompatible with the expected type for the block (to
which `!` is cast).
Fix#14100
changelog: [`unnecessary_semicolon`]: do not remove semicolon if it
could change the block type from `!` to `()`
Commit 2550530266 has extended the
`precedence` lint to include bitmasking and shift operations. The lint
is warn by default, and this generates many hits, especially in embedded
or system code, where it is very idiomatic to use expressions such as `1
<< 3 | 1 << 5` without parentheses.
This commit splits the recent addition into a new lint, which is put
into the "restriction" category, while the original one stays in
"complexity", because mixing bitmasking and arithmetic operations is
less typical.
Fix#14097
changelog: [`precedence_bits`]: new lint
Turns out I was completely overcomplicating myself,
there was no need for an external tool such as becnhv2
or even the original becnh, we already had the benchmarking
infrastructure right under our noses!
This PR implements a new **lintcheck** option called
--perf, using it as a flag will mean that lintcheck
builds Clippy as a release package and hooks perf to it.
The realization that lintcheck is already 90% of what
a benchmarking tool needs came to me in a dream.
Commit 2550530266 has extended the
`precedence` lint to include bitmasking and shift operations. The lint
is warn by default, and this generates many hits, especially in embedded
or system code, where it is very idiomatic to use expressions such as
`1 << 3 | 1 << 5` without parentheses.
This commit splits the recent addition into a new lint, which is put
into the "restriction" category, while the original one stays in
"complexity", because mixing bitmasking and arithmetic operations is
less typical.
Removing the semicolon of the last statement of an expressionless block
may change the block type even if the statement's type is `()`. If the
block type is `!` because of a systematic early return, typing it as
`()` may make it incompatible with the expected type for the block (to
which `!` is cast).
fix#13959
The current implementation of the `write_literal` and `print_literal`
lint performs escaping for the second argument of `write!` ,`writeln!`,
`print!` and `println!` of the suggestion by first replacing `"` with
`\"`, and then replacing `\` with `\\`. Performing these replacements in
this order may lead to unnecessary backslashes being added if the
original code contains `"` (e.g. `"` -> `\\"`), potentially resulting in
a suggestion that causes the code to fail to compile.
In the issue mentioned above, it’s suggested to use raw strings as raw
strings, but implementing this would require an ad-hoc change to the
current implementation, so it has been deferred. (I'll implement this in
another PR)
changelog: [`write_literal`]: fix incorrect escaping of suggestions
changelog: [`print_literal`]: fix incorrect escaping of suggestions
Currently, the CI pipeline triggers `Lintcheck` for all PRs. However,
this check takes significant amount of time and seems unnecessary for
some certain directories that are frequently updated.
r? flip1995
changelog: none
Add a new lint `doc_overindented_list_items` to detect and fix list
items
in docs that are overindented.
For example,
```rs
/// - first line
/// second line
fn foo() {}
```
this would be fixed to:
```rs
/// - first line
/// second line
fn foo() {}
```
This lint improves readabiliy and consistency in doc.
---
- \[x] Followed [lint naming conventions][lint_naming]
- \[x] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[x] Executed `cargo dev update_lints`
- \[x] Added lint documentation
- \[x] Run `cargo dev fmt`
[lint_naming]:
https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
changelog: [`doc_overindented_list_items`]: Added a new lint that
detects overindented list items in docs
fixes: #13601
Add a new lint `doc_overindented_list_items` to detect and fix list items
in docs that are overindented.
For example,
```rs
/// - first line
/// second line
fn foo() {}
```
this would be fixed to:
```rs
/// - first line
/// second line
fn foo() {}
```
This lint improves readabiliy and consistency in doc.
fix#14034
The currect implementation of `obfuscated_if_else` sometimes makes
incorrect suggestions when the original code have side effects (see the
example in the above issue). I think this can be fixed by changing the
applicability depending on whether it can have side effects or not.
changelog: [`obfuscated_if_else`]: change applicability when the
original code can have side effects
I opened https://github.com/rust-lang/rust-clippy/pull/13896 before.
However, I found that there're more cases where Clippy suggests to use
modules that belong to the `std` crate even in a `no_std` environment.
Therefore, this PR include the changes I've made in #13896 and new
changes to fix cases I found this time to prevent wrong suggestions in
`no_std` environments as well.
changelog: [`redundant_closure`]: correct suggestion in `no_std`
changelog: [`repeat_vec_with_capacity`]: correct suggestion in `no_std`
changelog: [`single_range_in_vec_init`]: don't emit suggestion to use
`Vec` in `no_std`
changelog: [`drain_collect`]: correct suggestion in `no_std`
changelog: [`map_with_unused_argument_over_ranges`]: correct suggestion
in `no_std`
also close#13895
Uplift `clippy::double_neg` lint as `double_negations`
Warns about cases like this:
```rust
fn main() {
let x = 1;
let _b = --x; //~ WARN use of a double negation
}
```
The intent is to keep people from thinking that `--x` is a prefix decrement operator. `++x`, `x++` and `x--` are invalid expressions and already have a helpful diagnostic.
I didn't add a machine-applicable suggestion to the lint because it's not entirely clear what the programmer was trying to achieve with the `--x` operation. The code that triggers the lint should always be reviewed manually.
Closes#82987
