fix `needless_borrow` suggestion
fixes: #2610
While I'm working on this, should needless_borrow be split into two? One lint for expressions and another for patterns. In expression it only lints when the compiler inserts a dereference, but for patterns it's whenever a double reference is created. I think at least the case where a double reference is needed should be split into a new lint as it's not 'needless', it can just be done without a ref binding.
For illustration:
```rust
fn foo(x: &&str) {}
match Some("test") {
// ref binding is useless here
Some(ref x) => *x,
_ => (),
}
match Some("test") {
// ref binding is useless here
Some(ref x) => x.len(),
_ => (),
}
match Some("test") {
// double reference is needed, but could be `Some(x) => foo(&x)`
Some(ref x) => foo(x),
_ => (),
}
```
changelog: Improve the suggestion for `needless_borrow` in patterns to change all usage sites as needed.
changelog: Add lint `ref_binding_to_reference`
Early return from LintPass registration when collecting metadata
This speeds up the metadata collection by 2-2.5x on my machine. During
metadata collection other lint passes don't have to be registered, only
the lints themselves.
cc #7172
r? `@xFrednet`
changelog: none
This speeds up the metadata collection by 2-2.5x on my machine. During
metadata collection other lint passes don't have to be registered, only
the lints themselves.
Rustup
r? `@ghost`
cc `@xFrednet` There was a change to the `rustc_span::FileName` removing the `Display` impl for it. I adapted the metadata collector to compile with that change. I'm not sure if I changed the behavior with this. The path to the string is now printed relative to the `clippy_lints` dir. So for example `src/swap.rs`. I think this should be fine, but probably something to be aware of.
changelog: none
Adding the default lint level to the metadata collection
I noticed while working on the website adaption that the lint groups still had the `clippy::` prefix in the JSON output. This PR removes this prefix and adds a `level` field to each lint and with that simplifies the website display and saves performance.
The deprecated lints get are assigned to the level `none`. This is a bit different in comparison to the current lint list, but I believe that this will look better overall. Unless there is any argument against this :).
That's it just a small baby PR in comparison to the original monster ^^
---
See: #7172 for the full metadata collection to-do list or to suggest a new feature in connection to it.
---
changelog: none
r? `@flip1995`
Implement the new desugaring from `try_trait_v2`
~~Currently blocked on https://github.com/rust-lang/rust/issues/84782, which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix.
`try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277
Unfortunately this is already touching a ton of things, so if you have suggestions for good ways to split it up, I'd be happy to hear them. (The combination between the use in the library, the compiler changes, the corresponding diagnostic differences, even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits.
r? `@ghost`
~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.
Don't lint `multiple_inherent_impl` with generic arguments
fixes: #5772
changelog: Treat different generic arguments as different types in `multiple_inherent_impl`
Deny warnings in every main sub-crate
Pointed out by `@xFrednet` in https://github.com/rust-lang/rust-clippy/pull/7229#issuecomment-842978909
This enables the same (rustc) lints in every main sub-crate:
- `clippy`
- `clippy_lints`
- `clippy_utils`
- `clippy_dev`
In addition it forwards the `deny-warnings` feature to those sub-crates, so we don't miss warnings that then become a problem during sync. (I wanted to fix that before, but forgot about it, so thanks for pointing it out `@xFrednet!)`
changelog: none
This enables the same warnings that are enabled in `clippy_lints` also
in `clippy_utils` and `clippy_dev`. Then it makes sure, that the
`deny-warnings` feature is passed down to `clippy_lints` and
`clippy_utils` when compiling Clippy.
Remove powi, "square can be computed more efficiently"
powi(2) produces exactly the same native code as x * x
powi was part of the [`suboptimal_flops`] lint
fixes#7058
changelog: Remove powi [`suboptimal_flops`], "square can be computed more efficiently"
Add `needless_bitwise_bool` lint
fixes#6827fixes#1594
changelog: Add ``[`needless_bitwise_bool`]`` lint
Creates a new `bitwise_bool` lint to convert `x & y` to `x && y` when both `x` and `y` are booleans. I also had to adjust thh `needless_bool` lint slightly, and fix a couple failing dogfood tests. I made it a correctness lint as per flip1995's comment [here](https://github.com/rust-lang/rust-clippy/pull/3385#issuecomment-434715723), from a previous WIP attempt at this lint.
Fix FPs about generic args
Fix 2 false positives in [`use_self`] and [`useless_conversion`] lints, by taking into account generic args and comparing them.
Fixes: #7205Fixes: #7206
changelog: Fix FPs about generic args in [`use_self`] and [`useless_conversion`] lints
New lint: `unused_async`
changelog: Adds a lint, `unused_async`, which checks for async functions with no await statements
`unused_async` is a lint that reduces code smell and overhead by encouraging async functions to be refactored into synchronous functions.
Fixes#7176
### Examples
```rust
async fn get_random_number() -> i64 {
4 // Chosen by fair dice roll. Guaranteed to be random.
}
```
Could be written as:
```rust
fn get_random_number() -> i64 {
4 // Chosen by fair dice roll. Guaranteed to be random.
}
```
Something like this, however, should **not** be caught by clippy:
```rust
#[async_trait]
trait AsyncTrait {
async fn foo();
}
struct Bar;
#[async_trait]
impl AsyncTrait for Bar {
async fn foo() {
println!("bar");
}
}
```
Stop linting `else if let` pattern in [`option_if_let_else`] lint
For readability concerns, it is counterproductive to lint `else if let` pattern.
Unfortunately the suggested code is much less readable.
Fixes: #7006
changelog: stop linting `else if let` pattern in [`option_if_let_else`] lint
Remove CrateNum parameter for queries that only work on local crate
The pervasive `CrateNum` parameter is a remnant of the multi-crate rustc idea.
Using `()` as query key in those cases avoids having to worry about the validity of the query key.
Metadata collection monster searching for Clippy's configuration options
This PR teaches our lovely metadata collection monster which configurations are available inside Clippy. It then adds a new *Configuration* section to the lint documentation.
---
The implementation uses the `define_Conf!` macro to create a vector of metadata during compilation. This enables easy collection and parsing without the need of searching for the struct during a lint-pass (and it's quite elegant IMO). The information is then parsed into an intermediate struct called `ClippyConfiguration` which will be saved inside the `MetadataCollector` struct itself. It is currently only used to generate the *Configuration* section in the lint documentation, but I'm thinking about adding an overview of available configurations to the website. Saving them in this intermediate state without formatting them right away enables this in the future.
The new parsing will also allow us to have a documentation that spans over multiple lines in the future. For example, this will be valid when the old script has been removed:
```rust
/// Lint: BLACKLISTED_NAME.
/// The list of blacklisted names to lint about. NB: `bar` is not here since it has legitimate uses
(blacklisted_names: Vec<String> = ["foo", "baz", "quux"].iter().map(ToString::to_string).collect())
```
The deprecation reason is also currently being collected but not used any further and that's basically it.
---
See: #7172 for the full metadata collection to-do list or to suggest a new feature in connection to it 🙃
---
changelog: none
r? `@flip1995`
cc `@camsteffen` It would be great if you could also review this PR as you have recently worked on Clippy's `define_Conf!` macro.
Add `cargo collect-metadata` as an cargo alias for the metadata collection lint
This PR adds a new alias to run the metadata collection monster on `clippy_lints`. I'm currently using it to create the `metadata_collection.json` file and I plan to use it in the `deply.sh` script. Having it as a new alias enables us to simply use:
```sh
cargo collect-metadata
```
It sometimes requires running `cargo clean` before collecting the metadata due to caching. I'm still debating if I should include a cargo clean as part of the `run_metadata_collection_lint` test or not. Input on this would be greatly appreciated 🙃
That's it, just a small change that can be reviewed and merged in parallel to #7214.
---
See: #7172 for the full metadata collection to-do list or to suggest a new feature in connection to it.
---
changelog: none
r? `@flip1995` btw. feel free to pass these PRs one to other team members as well if you want.
