New lint: [`self_named_constructor`]
Adds the `self_named_constructor` lint for detecting when an implemented method has the same name as the type it is implemented for.
changelog: [`self_named_constructor`]
closes: #7142
Add macro_braces lint to check for irregular brace use in certain macros
The name is a bit long but this sounds good as `#[allow(unconventional_macro_braces)]` and it seems more clear that we are talking about the macro call not macro definitions, any feedback let me know. Thanks!
fixes#7278
changelog: Add ``[`unconventional_macro_braces`]`` lint that checks for uncommon brace usage with macros.
Rename unconventional -> nonstandard, add config field
Add standard_macro_braces fields so users can specify macro names and
brace combinations to lint for in the clippy.toml file.
Fix errors caused by nonstandard_macro_braces in other lint tests
Fix users ability to override the default nonstandard macro braces
Add type position macros impl `check_ty`
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.
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");
}
}
```
The most recent changelog update 037ddf282b accompanying the 1.52 release added a second "Rust 1.52" section header, with the result that the Rust release announcement https://blog.rust-lang.org/2021/05/06/Rust-1.52.0.html is linking to the "current beta" changelog section for Clippy rather than the stable changelog. I don't know the release process but based on previous changes to this file, I assume the correct thing to do is to mark the topmost section as being for Rust 1.53, not 1.52.
Add lint to check for boolean comparison in assert macro calls
This PR adds a lint to check if an assert macro is using a boolean as "comparison value". For example:
```rust
assert_eq!("a".is_empty(), false);
```
Could be rewritten as:
```rust
assert!(!"a".is_empty());
```
PS: The dev guidelines are amazing. Thanks a lot for writing them!
changelog: Add `bool_assert_comparison` lint
* Added expression check for shared_code_in_if_blocks
* Finishing touches for the shared_code_in_if_blocks lint
* Applying PR suggestions
* Update lints yay
* Moved test into subfolder
Lint: filter(Option::is_some).map(Option::unwrap)
Fixes#6061
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog:
* add new lint for filter(Option::is_some).map(Option::unwrap)
First Rust PR, so I'm sure I've violated some idioms. Happy to change anything.
I'm getting one test failure locally -- a stderr diff for `compile_test`. I'm having a hard time seeing how I could be causing it, so I'm tentatively opening this in the hopes that it's an artifact of my local setup against `rustc`. Hoping it can at least still be reviewed in the meantime.
I'm gathering that since this is a method lint, and `.filter(...).map(...)` is already checked, the means of implementation needs to be a little different, so I didn't exactly follow the setup boilerplate. My way of checking for method calls seems a little too direct (ie, "is the second element of the expression literally the path for `Option::is_some`?"), but it seems like that's how some other lints work, so I went with it. I'm assuming we're not concerned about, eg, closures that just end up equivalent to `Option::is_some` by eta reduction.
