Commit graph

17548 commits

Author SHA1 Message Date
bors
df3804ae0a Auto merge of #10955 - Centri3:redundant_matches_guard, r=Alexendoo,blyxyas
new lint [`redundant_guards`]

Closes #7825, maybe somebody else can get the ranges lint in the comments?

changelog: New lint [`redundant_guards`]
2023-07-22 12:00:37 +00:00
Centri3
51b57723d1 new lint redundant_guards 2023-07-22 06:28:05 -05:00
bors
a44dcf80ef Auto merge of #10885 - max-niederman:redundant_local, r=Centri3
new lint: `redundant_locals`

This lint checks for code like the following:

```rs
let x = 1;
let x = x;
```

It checks (afaik) all cases where a binding is shadowed by its own value in the same block, including function parameters. This has no effect and is almost certainly accidental, so it's in the `correctness` category like `self_assignment`.

This also lays the groundwork for a more generalized version of #5102.

changelog: new lint: [`redundant_local`]
2023-07-22 10:54:16 +00:00
Max Niederman
008ba2b8bb
new lint: redundant_local
fix dogfood lints in `redundant_local`

keep `redundant_local` from running in proc macros

rewrite `redundant_local` as late pass

make redundant_local's `find_binding` more readable

pluralize `redundant_locals` name

add test for `redundant_locals` in macros

test `redundant_locals` in proc macros

use more destructuring in `redundant_locals`

fix: format redundant_locals.rs

ignore needless_pass_by_mut_ref in redundant_locals test
2023-07-21 18:14:03 -07:00
bors
58df1e64cb Auto merge of #11003 - Centri3:absolute_path, r=Alexendoo,blyxyas
New lint [`absolute_paths`]

Closes #10568

Maybe we should make the max segments allowed a configuration option? I see quite a bit of 3-segment paths in clippy, and while I think only really `<mod/type>::<item>` or `<item>` should be (usually) used but anything above may be too widespread 😕

PS, despite this being "max segments allowed" it only lints if it's absolute, as is the point of the lint, e.g., `std::io::ErrorKind::etc` is linted but `io::ErrorKind::NotFound::etc` isn't

changelog: New lint [`absolute_paths`]
2023-07-21 22:29:19 +00:00
Catherine
9cf1509b25 New lint absolute_paths 2023-07-21 17:26:58 -05:00
bors
d2c9047a92 Auto merge of #11205 - Centri3:#11201, r=Manishearth
[`inherent_to_string`]: Don't lint `unsafe` or `extern` fns

Fixes #11201

changelog: [`inherent_to_string`]: No longer lints `unsafe` or `extern` fns
2023-07-21 15:01:04 +00:00
Catherine Flores
f3f7f63c16 [inherent_to_string]: Don't lint unsafe or extern fns 2023-07-21 06:45:30 -05:00
bors
ee8a429792 Auto merge of #11188 - Centri3:#11178, r=blyxyas
Allow `Self::cmp(self, other)` as a correct impl

Fixes #11178

Also no longer checks if the method name is *just* cmp, but the path. That was an oversight on my part ^^

r? `@xFrednet`
(and `@blyxyas` too!)

changelog: [`incorrect_partial_ord_impl_on_ord_type`]: Now allows non-method calls to `cmp` like `Self::cmp(self, other)`
2023-07-20 22:37:02 +00:00
Catherine
a4c367d0e9 Allow Self::cmp(self, other) as a correct impl 2023-07-20 16:17:24 -05:00
bors
7c5095c502 Auto merge of #11195 - thvdveld:fix-option-env-ifs-equal-cond, r=Manishearth
fix: false positive for `option_env!` in `ifs_same_cond`

Clippy had a false positive for with `ifs_same_cond` when two if-let expressions have an `option_env!` macro. The fix is similar to the `env!` macro fix.

The following example had a clippy error:

```rust
if let Some(env1) = option_env!("ENV1") {
    // ...
} else if let Some(env2) = option_env!("ENV2") {
    // ...
}
```

See https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=01b85c61b56ddd900117fb247af04824

changelog: [`ifs_same_cond`]: fix false positive when using `option_env!` in if-let expressions.
2023-07-20 14:46:23 +00:00
bors
fca1f9aec5 Auto merge of #11106 - syvb:literal_unwrap_ice, r=dswij
[`unnecessary_literal_unwrap`]: Fix ICE on None.unwrap_or_default()

Fixes #11099
Fixes #11064

I'm running into #11099 (cc `@y21)` on my Rust codebase. Clippy ICEs on this code when evaluating the `unnecessary_literal_unwrap` lint:
```rust
fn main() {
    let val1: u8 = None.unwrap_or_default();
}
```

This fixes that ICE and adds an message specifically for that case:

```
error: used `unwrap_or_default()` on `None` value
  --> $DIR/unnecessary_literal_unwrap.rs:26:5
   |
LL |     None::<String>.unwrap_or_default();
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the `None` and `unwrap_or_default()`: `String::default()`
```

This PR also fixes the same ICE with `None.unwrap_or_else` (by giving the generic error message for the lint in that case).

changelog: Fix ICE in `unnecessary_literal_unwrap` on `None.unwrap_or_default()`
2023-07-20 10:55:30 +00:00
Thibaut Vandervelden
f743fec6b0 fix: false positive for option_env! in ifs
Clippy had a false positive for with `ifs_same_cond` when two
if-let expressions have an `option_env!` macro. The fix is similar to the
`env!` macro fix.

The following example had a clippy error:

```rust
if let Some(env1) = option_env!("ENV1") {
    // ...
} else if let Some(env2) = option_env!("ENV2") {
    // ...
}
```

See https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=01b85c61b56ddd900117fb247af04824

changelog: Fix [`ifs_same_cond`] false positive when using `option_env!` in if-let expressions.
2023-07-20 12:04:24 +02:00
bors
fbe292e563 Auto merge of #10971 - Centri3:unnecessary_cast_fully_qual_fix, r=dswij
Check for fully qualified paths in `unnecessary_cast`

Noticed this doesn't pick up `::std::primitive::u32` or the sort, now it does
changelog: none
2023-07-20 08:30:19 +00:00
bors
0f31fff59e Auto merge of #11194 - flip1995:new-reviewers, r=xFrednet
Add Centri3 and blyxyas to the reviewer rotation

And with that you will now be picked automatically by rustbot to review pull requests.

Welcome to the team!

Thank you for making Clippy better!

r? `@xFrednet`

changelog: New team members `@Centri3` and `@blyxyas`
2023-07-20 08:16:54 +00:00
Catherine
15b68c24b8 Extract the logic for if a snippet equals a type 2023-07-20 03:11:35 -05:00
Philipp Krones
579f1ec123
Add Centri3 and blyxyas to the reviewer rotation
And with that you will now be picked automatically by rustbot to review pull
requests.

Welcome to the team!
2023-07-20 09:49:21 +02:00
bors
d764a0ea5e Auto merge of #11161 - c410-f3r:let-chain, r=dswij
[significant_drop_tightening] Fix #11160

Fix #11160

```
changelog: [`significant_drop_tightening`]: Ignore literals in function returns
```
2023-07-20 07:28:08 +00:00
bors
d71fbb9db2 Auto merge of #11107 - Centri3:error_impl_error, r=Jarcho
New lint [`error_impl_error`]

Closes #11101

changelog: New lint [`error_impl_error`]
2023-07-20 02:07:27 +00:00
bors
0b63e95dce Auto merge of #10949 - y21:issue8010, r=Alexendoo
[`manual_filter_map`]: lint on `matches` and pattern matching

Fixes #8010

Previously this lint only worked specifically for a very limited set of methods on the filter call (`.filter(|opt| opt.is_some())` and `.filter(|res| res.is_ok())`). This PR extends it to also recognize `matches!` in the `filter` and pattern matching with `if let` or `match` in the `map`.

Example:
```rs
enum Enum {
  A(i32),
  B,
}

let _ = [Enum::A(123), Enum::B].into_iter()
  .filter(|x| matches!(x, Enum::A(_)))
  .map(|x| if let Enum::A(s) = x { s } else { unreachable!() });
```
Now suggests:
```diff
-  .filter(|x| matches!(x, Enum::A(_))).map(if let Enum::A(s) = x { s } else { unreachable!() })
+  .filter_map(|x| match x { Enum::A(s) => Some(s), _ => None })
```

Adding this required a somewhat large change in code because it originally seemed to be specifically written with only method calls in the filter in mind, and `matches!` has different behavior in the map, so this new setup should make it possible to support more "generic" cases that need different handling for the filter and map calls.

changelog: [`manual_filter_map`]: lint on `matches` and pattern matching (and some internal refactoring)
2023-07-19 12:59:51 +00:00
bors
7a34143fa3 Auto merge of #11135 - smoelius:unwrap_or_else_default-fp, r=Centri3
Fix `unwrap_or_else_default` false positive

This PR fixes a false positive in the handling of `unwrap_or_else` with a default value when the value is needed for type inference.

An easy example to exhibit the false positive is the following:
```rust
    let option = None;
    option.unwrap_or_else(Vec::new).push(1);
```
The following code would not compile, because the fact that the value is a `Vec` has been lost:
```rust
    let option = None;
    option.unwrap_or_default().push(1);
```
The fix is to:
- implement a heuristic to tell whether an expression's type can be determined purely from its subexpressions, and the arguments and locals they use;
- apply the heuristic to `unwrap_or_else`'s receiver.

The heuristic returns false when applied to `option` in the above example, but it returns true when applied to `option` in either of the following examples:
```rust
    let option: Option<Vec<u64>> = None;
    option.unwrap_or_else(Vec::new).push(1);
```
```rust
    let option = None::<Vec<u64>>;
    option.unwrap_or_else(Vec::new).push(1);
```

(Aside: https://github.com/rust-lang/rust-clippy/pull/10120 unfairly contained multiple changes in one PR. I am trying to break that PR up into smaller pieces.)

---

changelog: FP: [`unwrap_or_else_default`]: No longer lints if the default value is needed for type inference
2023-07-19 11:37:30 +00:00
bors
0fa1fd396e Auto merge of #11183 - Alexendoo:new-lint-template, r=xFrednet
Remove `#![allow(unused)]` and `--crate-name` from `cargo dev new_lint` generated tests

changelog: none

Also removes some unused flags from `ui-cargo` tests because the entrypoint is now the `Cargo.toml`, not the `.rs` files
2023-07-19 10:51:11 +00:00
Samuel Moelius
f583fd18e4 Fix unwrap_or_else_default false positive 2023-07-19 06:45:33 -04:00
Centri3
dcfc6a20db check for fully qualified paths in unnecessary_cast 2023-07-19 05:24:17 -05:00
bors
3dd6af957c Auto merge of #11046 - Centri3:iter_skip_zero, r=blyxyas
New lint [`iter_skip_zero`]

Idea came from my contribution to `unnecessary_cast` recently. Sorry about that 😅

Could be an issue if somebody manually implements `skip`, but I don't think anybody will (and this would be an issue with other lints too, afaik)

changelog: New lint [`iter_skip_zero`]
2023-07-19 09:03:40 +00:00
Catherine
4c79d8ace5 new lint iter_skip_zero 2023-07-19 03:26:15 -05:00
Catherine
19b0e84187 Remove the configuration option
Also no longer lints non-exported types now
2023-07-19 02:08:33 -05:00
bors
ec571555a8 Auto merge of #11052 - Centri3:string_lit_chars_any, r=Jarcho
New lint [`string_lit_chars_any`]

Closes #10389

This lint can probably be deprecated if/when rustc optimizes `.chars().any(...)`.

changelog: New lint [`string_lit_chars_any`]
2023-07-19 06:58:03 +00:00
Catherine
9d08502496 New lint [string_lit_chars_any] 2023-07-19 00:38:22 -05:00
bors
d4a6634d37 Auto merge of #11175 - y21:issue11174, r=Manishearth
[`redundant_pattern_matching`]: include guard in suggestion

Fixes #11174

changelog: [`redundant_pattern_matching`]: include guard in suggestion
2023-07-18 20:37:30 +00:00
Alex Macleod
f539e1a1db Remove unused flags from ui-cargo tests 2023-07-18 18:46:09 +00:00
Alex Macleod
9c6b17e24d Remove #![allow(unused)] and --crate-name from new_lint tests 2023-07-18 18:45:47 +00:00
Catherine
f4b3bb19c1 Add allow_private_error config option 2023-07-18 10:26:22 -05:00
Catherine
75e1329aac New lint [error_impl_error] 2023-07-18 10:26:12 -05:00
bors
9f0cbfd7df Auto merge of #11140 - Centri3:four_forward_slashes, r=blyxyas
New lint [`four_forward_slashes`]

Closes #9212

changelog: New lint [`four_forward_slashes`]
2023-07-18 12:56:18 +00:00
bors
747df85f95 Auto merge of #11171 - Centri3:tuple_array_conversions, r=llogiq
Rewrite [`tuple_array_conversions`]

Fixes #11100
Fixes #11144
Fixes #11124

#11082 still needs discussion and #11085 likely can't be fixed.

changelog: [`tuple_array_conversions`]: Move to `pedantic`
changelog: [`tuple_array_conversions`]: Don't lint if mutability of references changes
changelog: [`tuple_array_conversions`]: Don't lint if bindings don't come from the exact same pattern
changelog: [`tuple_array_conversions`]: Don't lint if bindings are used for more than just the conversion
2023-07-18 05:15:50 +00:00
y21
e7fd44f213 add guard to suggestion instead of not linting 2023-07-17 21:18:11 +02:00
y21
c26801ee92 [redundant_pattern_matching]: don't lint if if guards are present 2023-07-17 19:25:28 +02:00
bors
3e0170bff4 Auto merge of #11173 - Alexendoo:needless-return-fn-macro, r=Manishearth
Don't lint `needless_return` in fns across a macro boundary

Fixes #11167

changelog: none
2023-07-17 15:53:21 +00:00
bors
410456da51 Auto merge of #11116 - y21:format_collect, r=Manishearth
new lint: `format_collect`

A perf lint that looks for `format!`ing inside of `map`, then collecting it into a `String`. Did a quick benchmark locally and it's a bit more than 2x faster with fold.
`write!` is still not optimal (presumably because the fmt stuff goes through dynamic dispatch), but it's still a lot better than creating a new string on every element.
I thought about making a machine applicable suggestion, but there's a lot of suggestions that need to be made here, so I decided to just add help messages.

changelog: new lint: `format_collect`
2023-07-17 15:38:33 +00:00
Alex Macleod
d24f0d056f Don't lint needless_return in fns across a macro boundary 2023-07-17 14:03:00 +00:00
bors
54fa92287b Auto merge of #11172 - Alexendoo:tuple-array-conversions-nursery, r=xFrednet
Move tuple_array_conversions to nursery

changelog: Move [`tuple_array_conversions`] to `nursery` (Now allow-by-default)
<!-- FIY: Ignore this change, if the commit gets backported and also https://github.com/rust-lang/rust-clippy/pull/11146 -->
[#11172](https://github.com/rust-lang/rust-clippy/pull/11172)

The nursery change got lost in #11146 and it ended up in pedantic, this puts it in nursery and gives something to backport

r? `@xFrednet`
2023-07-17 12:18:27 +00:00
Alex Macleod
36f84a6176 Move tuple_array_conversions to nursery 2023-07-17 12:09:20 +00:00
Catherine
74a77047da Rewrite [tuple_array_conversions] 2023-07-17 05:36:50 -05:00
y21
c83d58f507 document that write!ing into a string never fails 2023-07-17 12:23:18 +02:00
y21
c3881569af new lint: format_collect 2023-07-17 12:13:34 +02:00
bors
568ccf3fc8 Auto merge of #11083 - sylvestre:autofix, r=dswij
[`semicolon_if_nothing_returned`]: add an autofix

changelog: [`semicolon_if_nothing_returned`]: add an autofix
2023-07-17 08:05:11 +00:00
bors
91095334bf Auto merge of #11168 - xFrednet:00000-free-ice-cream, r=flip1995
Update bug URL to use the ice template

The previous URL linked to the blank new issue from without any template. This will now link to the ICE template :)

* Before: https://github.com/rust-lang/rust-clippy/issues/new
* After: https://github.com/rust-lang/rust-clippy/issues/new?template=ice.yml

That's it, nothing too interesting besides that. For everyone reading this: here, have some free cream 🍨 🍦 and have a beautiful day. 🙃

changelog: none
2023-07-17 07:47:23 +00:00
Sylvestre Ledru
8ebdd62620 [semicolon_if_nothing_returned]: Update the tests with the autofix 2023-07-16 22:19:25 +02:00
bors
d9c24d1b1e Auto merge of #11169 - y21:new_lint_unelide_lifetimes, r=xFrednet
don't hide lifetimes for `LateContext`

Running `cargo dev new_lint --type methods` creates the lint file with hidden lifetimes for the `LateContext` parameter (i.e. `&LateContext`, when it should be `&LateContext<'_>`). This is already warned on with `#![warn(rust_2018_idioms)]`, so clippy should not use hidden lifetimes

changelog: none
2023-07-16 19:56:51 +00:00