Remove lintcheck log and add `--filter` option to lintcheck
This PR removes the really outdated lintcheck log from this repo and adds a new `--filter` option to force warnings of a lint. This also ignores `allow` attributes. I believe that this is a good thing, as we'll see if suppressed false positives are also fixed by the changes.
---
#### Example:
```sh
$ cargo lintcheck --filter identity_op
```
#### Output
```
clippy 0.1.59 (460bef22a 2021-12-08)
[..]/cargo-0.49.0/src/cargo/core/compiler/fingerprint.rs:1910:17 clippy::identity_op "the operation is ineffective. Consider reducing it to `(ret[0] as usize)`"
[..]/cargo-0.49.0/src/cargo/util/hex.rs:8:9 clippy::identity_op "the operation is ineffective. Consider reducing it to `num`"
[..]/libc-0.2.81/src/unix/linux_like/linux/mod.rs:2654:18 clippy::identity_op "the operation is ineffective. Consider reducing it to `(dev & 0x00000000000000ff)`"
[..]/libc-0.2.81/src/unix/linux_like/linux/mod.rs:2665:16 clippy::identity_op "the operation is ineffective. Consider reducing it to `(minor & 0x000000ff)`"
[..]/libc-0.2.81/src/unix/linux_like/mod.rs:1218:27 clippy::identity_op "the operation is ineffective. Consider reducing it to `IPOPT_CONTROL`"
[..]/rayon-1.5.0/src/slice/quicksort.rs:588:17 clippy::identity_op "the operation is ineffective. Consider reducing it to `len / 4`"
[..]/regex-1.3.2/src/dfa.rs:1380:14 clippy::identity_op "the operation is ineffective. Consider reducing it to `(empty_flags.start as u8)`"
Stats:
clippy::identity_op 7
ICEs:
```
Two of these lints are suppressed when lintcheck runs normally
---
changelog: none
r? `@matthiaskrgr` Feel free to reassign if you think that someone else would be a better reviewer 🙃
Add new lint to warn when #[must_use] attribute should be used on a method
This lint is somewhat similar to https://rust-lang.github.io/rust-clippy/master/index.html#must_use_candidate but also different: it emits a warning by default and only targets methods (so not functions nor associated functions).
Someone suggested it to me after this tweet: https://twitter.com/m_ou_se/status/1466439813230477312
I think it would reduce the number of cases of API misuses quite a lot.
What do you think?
---
changelog: Added new [`return_self_not_must_use`] lint
Ignore associated types in traits when considering type complexity
changelog: Ignore associated types in traits when checking ``[`type_complexity`]`` lint.
fixes#1013
Fix bad suggestion on `option_if_let_else` when there is complex subpat
closes#7991
Prefer not warning any complex subpat in `option_if_let_else` rather than suggesting obscure suggestions.
changelog: [`option_if_let_else`] does not warn when complex subpat is present
Clarify the purpose of the non_send lint
PR 2/2 for issue #8045. Tried to tone down the warning message and clarify the intention of the lint. Specifically, I added a description that this lint tries to detect "types that are not safe to be sent to another thread".
changelog: none
r? `@xFrednet`
Peel blocks and statements utils
changelog: none
* Rename `remove_blocks` to `peel_blocks`
* Add `peel_blocks_and_stmts`
* Various refactors to use the above utils
* The utils also now check `block.rules`
Parenthesize blocks in `needless_bool` suggestion
Because the `if .. {}` statement already puts the condition in expression scope, contained blocks would be parsed as complete
statements, so any `&` binary expression whose left operand ended in a block would lead to a non-compiling suggestion.
We identify such expressions and add parentheses. Note that we don't make a difference between normal and unsafe blocks because the parsing problems are the same for both.
This fixes#8052.
---
changelog: none
Because the `if .. {}` statement already puts the condition in
expression scope, contained blocks would be parsed as complete
statements, so any `&` binary expression whose left operand ended in a
block would lead to a non-compiling suggestion.
This adds a visitor to identify such expressions and add parentheses.
This fixes#8052.
Fix some false negatives for [`single_char_pattern`]
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: Fix some false negatives for [`single_char_pattern`]
I noticed that clippy wasn't complaining about my usage of `split_once("x")` in a personal project so I updated the list of functions.
I had to update the test case for an unrelated issue because replace is now included in the list of functions to be linted.
Enable rustbot shortcuts for rust-clippy
This enables shortcuts for ``@rustbot`.` Just a quality of life feature for contributors.
|Shortcut| Full comment |
|---|---|
| ``@rustbot` ready` | ``@rustbot` label -S-waiting-on-author +S-waiting-on-review` |
| ``@rustbot` author` | ``@rustbot` label +S-waiting-on-author -S-waiting-on-review` |
See: https://github.com/rust-lang/triagebot/wiki/Shortcuts
The documentation also states that the author/assignee will be pinged. However, this doesn't seem to be the case, it at least hasn't done so for me and in this [PR](https://github.com/rust-lang/rust/pull/90642#issuecomment-962465404)
---
changelog: none
Consider NonNull as a pointer type
PR 1/2 for issue #8045. Add `NonNull` as a pointer class to suppress false positives like `UnsafeCell<NonNull<()>>`. However, this change is not sufficient to handle the cases shared in gtk-rs and Rug in the issue.
changelog: none
r? `@xFrednet`
Escape backslash in single_char_pattern.rs
Escape backslash in single_char_pattern.
Previously, the proposed clippy fix for a single backslash in raw strings ```r"\"``` or ```r#"\"#``` was also only an unescaped, *single* ```'\'```:
```shell
warning: single-character string constant used as pattern
2 | let s = r#"abc\xyz/"#.find(r"\");
| ^^^^ help: try using a `char` instead: `'\'`
|
= note: `#[warn(clippy::single_char_pattern)]` on by default
```
This PR corrects this to a properly escaped *double* backslash ```'\\'```.
I haven't come up with any other problematic cases, a single quote was already handled.
Closes: #8060
changelog: Escape backslash in ``[`single_char_pattern`]``
Fix `any()` not taking reference in `search_is_some` lint
`find` gives reference to the item, but `any` does not, so suggestion is broken in some specific cases.
Fixes: #7392
changelog: [`search_is_some`] Fix suggestion for `any()` not taking item by reference
Cleanup: Eliminate ConstnessAnd
This is almost a behaviour-free change and purely a refactoring. "almost" because we appear to be using the wrong ParamEnv somewhere already, and this is now exposed by failing a test using the unstable `~const` feature.
We most definitely need to review all `without_const` and at some point should probably get rid of many of them by using `TraitPredicate` instead of `TraitRef`.
This is a continuation of https://github.com/rust-lang/rust/pull/90274.
r? `@oli-obk`
cc `@spastorino` `@ecstatic-morse`
