Update lintcheck output to use tables and add markdown support
This PR updates changes lintcheck's output to use text tables and adds a markdown option to use Markdown links in the reports table. At first, I tried to keep the original output format, but the loading of old stats broke with the markdown option. The old format is therefore sadly incompatible with the new one. I can if requested make it in a way that the markdown output is only and optional additional output, but that would require more work for little benefit IMO.
For now, lintcheck has two output types. Here are the examples (best viewed on desktop):
<details>
<summary>`cargo lintcheck --only anyhow`</summary>
```txt
clippy 0.1.59 (460bef22a 2021-12-08)
### Reports
target/lintcheck/sources/anyhow-1.0.38/build.rs:1:null clippy::cargo_common_metadata "package `anyhow` is missing `package.keywords` metadata"
target/lintcheck/sources/anyhow-1.0.38/src/error.rs:350:5 clippy::missing_panics_doc "docs for function which may panic missing `# Panics` section"
target/lintcheck/sources/anyhow-1.0.38/src/lib.rs:1:null clippy::cargo_common_metadata "package `anyhow` is missing `package.keywords` metadata"
### Stats:
| lint | count |
| -------------------------------------------------- | ----- |
| clippy::missing_panics_doc | 1 |
| clippy::cargo_common_metadata | 2 |
### ICEs:
```
</details>
<details>
<summary>`cargo lintcheck --only anyhow --markdown` (The file links only work locally)</summary>
clippy 0.1.59 (460bef22a 2021-12-08)
### Reports
| file | lint | message |
| --- | --- | --- |
| [`anyhow-1.0.38/build.rs:1:null`](../target/lintcheck/sources/anyhow-1.0.38/build.rs#L1) | `clippy::cargo_common_metadata` | "package `anyhow` is missing `package.keywords` metadata" |
| [`anyhow-1.0.38/src/error.rs:350:5`](../target/lintcheck/sources/anyhow-1.0.38/src/error.rs#L350) | `clippy::missing_panics_doc` | "docs for function which may panic missing `# Panics` section" |
| [`anyhow-1.0.38/src/lib.rs:1:null`](../target/lintcheck/sources/anyhow-1.0.38/src/lib.rs#L1) | `clippy::cargo_common_metadata` | "package `anyhow` is missing `package.keywords` metadata" |
### Stats:
| lint | count |
| -------------------------------------------------- | ----- |
| clippy::missing_panics_doc | 1 |
| clippy::cargo_common_metadata | 2 |
### ICEs:
</details>
The table margins are so large to keep the table inline for long file names and lint names
---
changelog: none
r? `@matthiaskrgr`
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
