Split `needless_borrow` into two lints
Splits off the case where the borrow is used as a generic argument to a function. I think the two cases are different enough to warrant a separate lint.
The tests for the new lint have been reordered to group related parts together. Two warning have been dropped, one looked like it was testing the generic argument form, but it ends up triggering the auto-deref variant. The second was just a redundant test that didn't do anything interesting.
An issue with cycle detection is also included. The old version was checking if a cycle was reachable from a block when it should have been checking if the block is part or a cycle.
As a side note, I'm liking the style of just jamming all the tests into separate scopes in main.
changelog: Split off `needless_borrows_for_generic_args` from `needless_borrow`
[`filter_map_bool_then`]: include multiple derefs from adjustments
In #11506 this lint was improved to suggest one deref if the bool is behind references (fixed the FP #11503), however it might need multiple dereferences if the bool is behind multiple layers of references or custom derefs. E.g. `&&&bool` needs `***b`.
changelog: [`filter_map_bool_then`]: suggest as many dereferences as there are needed to get to the bool
add extra `byref` checking for the guard's local
changelog: [`redundant_guards`]: Now checks if the variable is bound using `ref` before linting.
The lint should not be emitted, when the local variable is bind by-ref in the pattern.
fixes#11465
[`useless_conversion`]: don't lint if type parameter has unsatisfiable bounds for `.into_iter()` receiver
Fixes#11300.
Before this PR, clippy assumed that if it sees a `f(x.into_iter())` call and the type at that argument position is generic over any `IntoIterator`, then the `.into_iter()` call must be useless because `x` already implements `IntoIterator`, *however* this assumption is not right if the generic parameter has more than just the `IntoIterator` bound (because other traits can be implemented for the IntoIterator target type but not the IntoIterator implementor, as can be seen in the linked issue: `<[i32; 3] as IntoIterator>::IntoIter` satisfies `ExactSizeIterator`, but `[i32; 3]` does not).
So, this PR makes it check that the type parameter only has a single `IntoIterator` bound. It *might* be possible to check if the type of `x` in `f(x.into_iter())` satisfies all the bounds on the generic type parameter as defined on the function (which would allow removing the `.into_iter()` call even with multiple bounds), however I'm not sure how to do that, and the current fix should always work.
**Edit:** This PR has been changed to check if any of the bounds don't hold for the type of the `.into_iter()` receiver, so we can still lint in some cases.
changelog: [`useless_conversion`]: don't lint `.into_iter()` if type parameter has multiple bounds
fix filter_map_bool_then with a bool reference
changelog: [`filter_map_bool_then`]: Fix the incorrect autofix when the `bool` in question is a reference.
fix#11503
[`extra_unused_type_parameters`]: Fix edge case FP for parameters in where bounds
Generic parameters can end up being used on the left side of where-bounds if they are not directly bound but instead appear nested in some concrete generic type. Therefore, we should walk the left side of where bounds, but only if the bounded type is *not* a generic param, in which case we still need to ignore the bound.
Fixes#11302
changelog: [`extra_unused_type_parameters`]: Fix edge case false positive for parameters in where bounds
[`len_without_is_empty`]: follow type alias to find inherent `is_empty` method
Fixes#11165
When we see an `impl B` and `B` is a type alias to some type `A`, then we need to follow the type alias to look for an `is_empty` method on the aliased type `A`. Before this PR, it'd get the inherent impls of `B`, which there aren't any and so it would warn that there isn't an `is_empty` method even if there was one.
Passing the type alias `DefId` to `TyCtxt::type_of` gives us the aliased `DefId` (or simply return the type itself if it wasn't a type alias) so we can just use that
changelog: [`len_without_is_empty`]: follow type alias to find inherent `is_empty` method
[`implied_bounds_in_impls`]: include (previously omitted) associated types in suggestion
Fixes#11435
It now includes associated types from the implied bound that were omitted in the second bound. Example:
```rs
fn f() -> impl Iterator<Item = u8> + ExactSizeIterator> {..}
```
Suggestion before this change:
```diff
- pub fn my_iter() -> impl Iterator<Item = u32> + ExactSizeIterator {
+ pub fn my_iter() -> impl ExactSizeIterator {
```
It didn't include `<Item = u32>` on `ExactSizeIterator`. Now, with this change, it does.
```diff
- pub fn my_iter() -> impl Iterator<Item = u32> + ExactSizeIterator {
+ pub fn my_iter() -> impl ExactSizeIterator<Item = u32> {
```
We also now extend the span to include not just possible `+` ahead of it, but also behind it (an example for this is in the linked issue as well).
**Note:** The overall diff is a bit noisy, because building up the suggestion involves quite a bit more logic now and I decided to extract that into its own function. For that reason, I split this PR up into two commits. The first commit contains the actual "logic" changes. Second commit just moves code around.
changelog: [`implied_bounds_in_impls`]: include (previously omitted) associated types in suggestion
changelog: [`implied_bounds_in_impls`]: include the `+` behind bound if it's the last bound
Rename incorrect_impls to non_canonical_impls, move them to warn by default
The wording/category of these feel too strong to me, I would expect most of the time it's linting the implementations aren't going to be *incorrect*, just unnecessary
changelog: rename `incorrect_clone_impl_on_copy_type` to [`non_canonical_clone_impl`]
changelog: rename `incorrect_partial_ord_impl_on_ord_type` to [`non_canonical_partial_ord_impl`]
changelog: Move [`non_canonical_clone_impl`], [`non_canonical_partial_ord_impl`] to suspicious
Preserve literals and range kinds in `manual_range_patterns`
Fixes#11461
Also enables linting when there are 3 or fewer alternatives if one of them is already a range pattern
changelog: none
[`slow_vector_initialization`]: use the source span of vec![] macro and fix another FP
Fixes#11408
<details>
<summary>Also fixes a FP when the vec initializer comes from a macro other than `vec![]`</summary>
```rs
macro_rules! x {
() => { vec![] }
}
fn f() {
let mut v = x!();
v.resize(10, 0);
}
```
This shouldn't warn. The `x!` macro might be doing other things, so just replacing `x!()` with `vec![0; 10]` is not always an option.
</details>
I added some test cases for macro expansions, however I don't think there's a way to write a test for that specific warning that appeared in the linked issue. As far as I understand, that happens when the rust-src rustup component isn't installed (so the stdlib source is unavailable) and the span points to the `vec![]` *expansion*, instead of the `vec![]` that the user wrote.
changelog: [`slow_vector_initialization`]: use the source span of `vec![]` macro
changelog: [`slow_vector_initialization`]: only warn on `vec![]` expansions and allow other macros
Fix `i686-unknown-linux-gnu` CI job
When testing https://github.com/oli-obk/ui_test/pull/161 I gave `--ignored` a try, I was surprised to see many of the 32bit tests passing even though I'm on a 64bit target
Turns out the `.stderr`s were incorrect, and our `i686-unknown-linux-gnu` job has been running `x86_64-unknown-linux-gnu` so it didn't get picked up
changelog: none
fix fp when [`undocumented_unsafe_blocks`] not able to detect comment on globally defined const/static variables
fixes: #11246
changelog: fix detection on global variables for [`undocumented_unsafe_blocks`]
skip `todo!()` in `never_loop`
As promised in #11450, here is an implementation which skips occurrences of the `todo!()` macro.
changelog: [`never_loop`]: skip loops containing `todo!()`
Don't pass extra generic arguments in `needless_borrow`
fixes#10253
Also switches to using `implements_trait` which does ICE when clippy's debug assertions are enabled.
changelog: None
[`implied_bounds_in_impls`]: don't ICE on default generic parameter and move to nursery
Fixes#11422
This fixes two ICEs ([1](https://github.com/rust-lang/rust-clippy/issues/11422#issue-1872351763), [2](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2901e6febb479d3bd2a74f8a5b8a9305)), and moves it to nursery for now, because this lint needs some improvements in its suggestion (see #11435, for one such example).
changelog: Moved [`implied_bounds_in_impls`] to nursery (Now allow-by-default)
[#11437](https://github.com/rust-lang/rust-clippy/pull/11437)
changelog: [`implied_bounds_in_impls`]: don't ICE on default generic parameter in supertrait clause
r? `@xFrednet` (since you reviewed my PR that added this lint, I figured it might make sense to have you review this as well since you have seen this code before. If you don't want to review this, sorry! Feel free to reroll then)
--------
As for the ICE, it's pretty complicated and very confusing imo, so I'm going to try to explain the idea here (partly for myself, too, because I've confused myself several times writing- and fixing this):
<details>
<summary>Expand</summary>
The general idea behind the lint is that, if we have this function:
```rs
fn f() -> impl PartialEq<i32> + PartialOrd<i32> { 0 }
```
We want to lint the `PartialEq` bound because it's unnecessary. That exact bound is already specified in `PartialOrd<i32>`'s supertrait clause:
```rs
trait PartialOrd<Rhs>: PartialEq<Rhs> {}
// PartialOrd<i32>: PartialEq<i32>
```
The way it does this is in two steps:
- Go through all of the bounds in the `impl Trait` return type and collect each of the trait's supertrait bounds into a vec. We also store the generic arguments for later.
- `PartialEq` has no supertraits, nothing to add.
- `PartialOrd` is defined as `trait PartialOrd: PartialEq`, so add `PartialEq` to the list, as well as the generic argument(s) `<i32>`
Once we are done, we have these entries in the vec: `[(PartialEq, [i32])]`
- Go through all the bounds again, and looking for those bounds that have their trait `DefId` in the implied bounds vec.
- `PartialEq` is in that vec. However, that is not enough, because the trait is generic. If the user wrote `impl PartialEq<String> + PartialOrd<i32>`, then `PartialOrd` clearly doesn't imply `PartialEq`. Which means, we also need to check that the generic parameters match. This is why we also collected the generic arguments in `PartialOrd<i32>`. This process of checking generic arguments is pretty complicated and is also where the two ICEs happened.
The way it checks that the generic arguments match is by comparing the generic parameters in the super trait clause:
```rs
trait PartialOrd<Rhs>: PartialEq<Rhs> {}
// ^^^^^^^^^^^^^^
```
...this needs to match...
```rs
fn f() -> impl PartialEq<i32> + ...
// ^^^^^^^^^^^^^^
```
In the compiler, the `Rhs` generic parameter is its own type and we cannot just compare it to `i32`. We need to "substitute" it.
Internally, `Rhs` is represented as `Rhs#1` (the number next to # represents the type parameter index. They start at 0, but 0 is "reserved" for the implicit `Self` generic parameter).
How do we go from `Rhs#1` to `i32`? Well, we know that all the generic parameters had to be substituted in the `impl ... + PartialOrd<i32>` type. So we subtract 1 from the type parameter index, giving us 0 (`Self` is not specified in that list of arguments). We use that as the index into the generic argument list `<i32>`. That's `i32`. Now we know that the supertrait clause looks like `: PartialEq<i32>`.
Then, we can compare that to what the user actually wrote on the bound that we think is being implied: `impl PartialEq<i32> + ...`.
Now to the actual bug: this whole logic doesn't take into account *default* generic parameters. Actually, `PartialOrd` is defined like this:
```rs
trait PartialOrd<Rhs = Self>: PartialEq<Rhs> {}
```
If we now have a function like this:
```rs
fn f() -> impl PartialOrd + PartialEq {}
```
that logic breaks apart... We look at the supertrait predicate `: PartialEq<Rhs>` (`Rhs` is `Rhs#1`), then take the first argument in the generic argument list `PartialEq<..>` to resolve the `Rhs`, but at this point we crash because there *is no* generic argument.
The index 0 is out of bounds. If this happens (and we even get to linting here, which could only happen if it passes typeck), it must mean that that generic parameter has a default type that is not required to be specified.
This PR changes the logic such that if we have a type parameter index that is out of bounds, it looks at the definition of the trait and check that there exists a default type that we can use instead.
So, we see `<Rhs = Self>`, and use `Self` for substitution, and end up with this predicate: `: PartialEq<Self>`. No crash this time.
</details>
Also stabilizes saturating_int_assign_impl, gh-92354.
And also make pub fns const where the underlying saturating_*
fns became const in the meantime since the Saturating type was
created.
Bump ui_test
This makes `ui_test` parse `--bless` and allows a follow up change to use `Mode::Error` (instead of `Mode::Yolo`) with `RustfixMode::Everything`
changelog: none
Fix span when linting `explicit_auto_deref` immediately after `needless_borrow`
fixes#11366
changelog: `explicit_auto_deref`: Fix span when linting immediately after `needless_borrow`
Add config flag for reborrows in explicit_iter_loop
This PR adds a config flag for enforcing explicit into iter lint for reborrowed values. The config flag, `enforce_iter_loop_reborrow`, can be added to clippy.toml files to enable the linting behaviour. By default the reborrow lint is disabled.
fixes: #11074
changelog: [`explicit_iter_loop`]: add config flag `enforce_iter_loop_reborrow` to disable reborrow linting by default
new lint: `iter_out_of_bounds`
Closes#11345
The original idea in the linked issue seemed to be just about arrays afaict, but I extended this to catch some other iterator sources such as `iter::once` or `iter::empty`.
I'm not entirely sure if this name makes a lot of sense now that it's not just about arrays anymore (specifically, not sure if you can call `.take(1)` on an `iter::Empty` to be "out of bounds"?).
changelog: [`iter_out_of_bounds`]: new lint
[`unnecessary_unwrap`]: lint on `.as_ref().unwrap()`
Closes#11371
This turned out to be a little more code than I originally thought, because the lint also makes sure to not lint if the user tries to mutate the option:
```rs
if option.is_some() {
option = None;
option.unwrap(); // don't lint here
}
```
... which means that even if we taught this lint to recognize `.as_mut()`, it would *still* not lint because that would count as a mutation. So we need to allow `.as_mut()` calls but reject other kinds of mutations.
Unfortunately it doesn't look like this is possible with `is_potentially_mutated` (seeing what kind of mutation happened).
This replaces it with a custom little visitor that does basically what it did before, but also allows `.as_mut()`.
changelog: [`unnecessary_unwrap`]: lint on `.as_ref().unwrap()`
skip float_cmp check if lhs is a custom type
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: [`float_cmp`]: allow float eq comparison when lhs is a custom type that implements PartialEq<f32/f64>
If the lhs of a comparison is not float, it means there is a user implemented PartialEq, and the caller is invoking that custom version of `==`, instead of the default floating point equal comparison.
People may wrap f32 with a struct (say `MyF32`) and implement its PartialEq that will do the `is_close()` check, so that `MyF32` can be compared with either f32 or `MyF32`.
[`if_then_some_else_none`]: look into local initializers for early returns
Fixes#11394
As the PR title says, problem was that it only looked for early returns in semi statements. Local variables don't count as such, so it didn't count `let _v = x?;` (or even just `let _ = return;`) as a possible early return and didn't realize that it can't lint then.
Imo the `stmts_contains_early_return` function that was used before is redundant. `contains_return` could already do that if we just made the parameter a bit more generic, just like `for_each_expr`, which can already accept `&[Stmt]`
changelog: [`if_then_some_else_none`]: look into local initializers for early returns
This commit adds a config flag for enforcing explicit into iter lint
for reborrowed values. The config flag, enforce_iter_loop_reborrow, can be
added to clippy.toml files to enable the linting behaviour. By default
the lint is not enabled.
fix the uitest `enum_clike_unportable_variant`
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: none
fix "derivable_impls: attributes are ignored"
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: [`derivable_impls`]: allow the lint when the trait-impl methods has any attribute.
Added new lint: `reserve_after_initialization`
Closes https://github.com/rust-lang/rust-clippy/issues/11330.
A new lint that informs the user about a more concise way to create a vector with a known capacity.
Example:
```rust
let mut v: Vec<usize> = vec![];
v.reserve(10);
```
Produces the following help:
```rust
|
2 | / let mut v: Vec<usize> = vec![];
3 | | v.reserve(10);
| |__________________^ help: consider using `Vec::with_capacity(space_hint)`: `let v: Vec<usize> = Vec::with_capacity(10);`
|
```
And can be rewritten as:
```rust
let v: Vec<usize> = Vec::with_capacity(10);
```
changelog: new lint [`reserve_after_initialization`]
Fix tuple_array_conversions lint on nightly
```
changelog: ICE: [`tuple_array_conversions`]: Don't expect array length to always be usize
```
tl;dr: changed [`Const::eval_target_usize`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/ty/consts.rs#L359) to [`Consts::try_eval_target_usize`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/ty/consts.rs#L327) to get rid of ICE.
I have encountered a problem with clippy: it caught ICE when working with a codebase that uses a lot of nightly features.
Here's a (stripped) ICE info:
```
error: internal compiler error: /rustc/5c6a7e71cd66705c31c9af94077901a220f0870c/compiler/rustc_middle/src/ty/consts.rs:361:32: expected usize, got Const { ty: usize, kind: N/#1 }
thread 'rustc' panicked at /rustc/5c6a7e71cd66705c31c9af94077901a220f0870c/compiler/rustc_errors/src/lib.rs:1635:9:
Box<dyn Any>
stack backtrace:
...
16: 0x110b9c590 - rustc_middle[449edf845976488d]::util:🐛:bug_fmt
17: 0x102f76ae0 - clippy_lints[71754038dd04c2d2]::tuple_array_conversions::all_bindings_are_for_conv
...
```
I don't really know what's going on low-level-wise, but seems like this lin assumed that the length of the array can always be treated as `usize`, and *I assume* this doesn't play well with `feat(generic_const_exprs)`.
I wasn't able to build a minimal reproducible example, but locally this fix does resolve the issue.
key idea:
for `f` in `.map(f)` and `.for_each(f)`:
1. `f` must be a closure with one parameter
2. don't lint if mutable paramter in clsure `f`: `|mut x| ...`
3. don't lint if parameter is moved
[new_without_default]: include `where` clause in suggestions, make applicable
changelog: [`new_without_default`]: include `where` clause in suggestions
Correctly handle async blocks for NEEDLESS_PASS_BY_REF_MUT
Fixes https://github.com/rust-lang/rust-clippy/issues/11299.
The problem was that the `async block`s are popping a closure which we didn't go into, making it miss the mutable access to the variables.
cc `@Centri3`
changelog: none
[`useless_conversion`]: only lint on paths to fn items and fix FP in macro
Fixes#11065 (which is actually two issues: an ICE and a false positive)
It now makes sure that the function call path points to a function-like item (and not e.g. a `const` like in the linked issue), so that calling `TyCtxt::fn_sig` later in the lint does not ICE (fixes https://github.com/rust-lang/rust-clippy/issues/11065#issuecomment-1616836099).
It *also* makes sure that the expression is not part of a macro call (fixes https://github.com/rust-lang/rust-clippy/issues/11065#issuecomment-1616919639). ~~I'm not sure if there's a better way to check this other than to walk the parent expr chain and see if any of them are expansions.~~ (edit: it doesn't do this anymore)
changelog: [`useless_conversion`]: fix ICE when call receiver is a non-fn item
changelog: [`useless_conversion`]: don't lint if argument is a macro argument (fixes a FP)
r? `@llogiq` (reviewed #10814, which introduced these issues)
Correctly handle async blocks for NEEDLESS_PASS_BY_REF_MUT
Fixes https://github.com/rust-lang/rust-clippy/issues/11299.
The problem was that the `async block`s are popping a closure which we didn't go into, making it miss the mutable access to the variables.
cc `@Centri3`
changelog: none
[`useless_conversion`]: only lint on paths to fn items and fix FP in macro
Fixes#11065 (which is actually two issues: an ICE and a false positive)
It now makes sure that the function call path points to a function-like item (and not e.g. a `const` like in the linked issue), so that calling `TyCtxt::fn_sig` later in the lint does not ICE (fixes https://github.com/rust-lang/rust-clippy/issues/11065#issuecomment-1616836099).
It *also* makes sure that the expression is not part of a macro call (fixes https://github.com/rust-lang/rust-clippy/issues/11065#issuecomment-1616919639). ~~I'm not sure if there's a better way to check this other than to walk the parent expr chain and see if any of them are expansions.~~ (edit: it doesn't do this anymore)
changelog: [`useless_conversion`]: fix ICE when call receiver is a non-fn item
changelog: [`useless_conversion`]: don't lint if argument is a macro argument (fixes a FP)
r? `@llogiq` (reviewed #10814, which introduced these issues)
Use ui_test's Windows path backslash heuristic
changelog: none
Instead of unconditionally replacing `\` with `/` we now use [`Match::PathBackslash`](https://docs.rs/ui_test/latest/ui_test/enum.Match.html#variant.PathBackslash) to only replace backslashes in paths that look like windows paths
`ui-toml` and `ui-cargo` tests still use the old way because they produce verbatim paths on windows in some tests (`\\?\C:\foo\...`) which was finnicky to get the replacement order correct with
Also removes the `ui_test` -> `compiletest` alias and `VarGuard`
Fix SPEEDTEST instructions and output
* `--nocapture` hasn't been needed anymore since forever (even before `ui_test`)
* the result was dividing by 1000 instead of the number of test runs, giving bogus (but still useful for the purpose) timing results.
changelog: fix SPEEDTEST instructions and output
redundant_locals: fix FPs on mutated shadows
Fixes#11290.
When a mutable binding is shadowed by
a mutable binding of the same name in a different scope, mutations in that scope have different meaning.
This PR fixes spurious `redundant_locals` emissions on such locals.
cc `@Centri3,` `@flip1995`
changelog: [`redundant_locals`]: fix false positives on mutated shadows
Rustup
r? `@ghost`
cc `@max-niederman` With the latest sync, I'm getting a lot of FP in the `redundant_locals` lint you recently added. Any ideas where this could come from?
changelog: none
When a mutable binding is shadowed by
a mutable binding of the same name in a different scope,
mutations in that scope have different meaning.
This commit fixes spurious `redundant_locals` emissions
on such locals.
[`redundant_guards`]: don't lint on float literals
Fixes#11304
changelog: [`redundant_guards`]: don't lint on float literals
r? `@Centri3` i figured you are probably a good reviewer for this since you implemented the lint ^^
redundant_type_annotations: only pass certain def kinds to type_of
Fixes#11190Fixesrust-lang/rust#113516
Also adds an `is_lint_allowed` check to skip the lint when it's not needed
changelog: none
Add `internal_features` lint
Implements https://github.com/rust-lang/compiler-team/issues/596
Also requires some more test blessing for codegen tests etc
`@jyn514` had the idea of just `allow`ing the lint by default in the test suite. I'm not sure whether this is a good idea, but it's definitely one worth considering. Additional input encouraged.
Fix `suspicious_xor_used_as_pow.rs` performance
The original `suspicious_xor_used_as_pow` lint had poor performance, so I fixed that + a little refactor so that module is readable.
**107 millis. -> 106 millis.** Using `SPEEDTEST` on Rust's VMs
fix#11060
changelog: [`suspicious_xor_used_as_pow`]: Improve performance by 0.934%
It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP #596.
We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.
Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).
We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^
New lint `ignored_unit_patterns`
This idea comes from #11238. I've put the lint in `pedantic` as it might trigger numerous positives (three in Clippy itself).
changelog: [`ignored_unit_patterns`]: new lint
Suppress `question_mark` warning if `question_mark_used` is not allowed
Closes#11283
changelog: [`question_mark`]: Don't lint if `question_mark_used` is not allowed
Rename and allow `cast_ref_to_mut` lint
This PR is a small subset of https://github.com/rust-lang/rust/pull/112431, that is the renaming of the lint (`cast_ref_to_mut` -> `invalid_reference_casting`).
BUT also temporarily change the default level of the lint from deny-by-default to allow-by-default until https://github.com/rust-lang/rust/pull/112431 is merged.
r? `@Nilstrieb`
new lint: [`readonly_write_lock`]
Closes#8555
A new lint that catches `RwLock::write` calls to acquire a write lock only to read from it and not actually do any writes (mutations).
changelog: new lint: [`readonly_write_lock`]
Now `option_env_unwrap` warns even if a variable isn't set at compiletime
Fixes#10742
changelog: Fix false negative where `option_env_unwrap` wouldn't warn if the env variable isn't set at compile-time.
Currently, Clippy, Miri, Rustfmt, and rustc all use an environment variable to
indicate that output should be blessed, but they use different variable names.
In order to improve consistency, this patch applies the following changes:
- Emit `RUSTC_BLESS` within `prepare_cargo_test` so it is always
available
- Change usage of `MIRI_BLESS` in the Miri subtree to use `RUSTC_BLESS`
- Change usage of `BLESS` in the Clippy subtree to `RUSTC_BLESS`
- Change usage of `BLESS` in the Rustfmt subtree to `RUSTC_BLESS`
- Adjust the blessable test in `rustc_errors` to use this same
convention
- Update documentation where applicable
Any tools that uses `RUSTC_BLESS` should check that it is set to any value
other than `"0"`.
Fix integration tests #2
fix integration tests.
It turned out that the following tests fail to build at all:
chalk, combine, stdarch and hyper.
This is often a problem of passing `--all-targets --all-features`, in case of combine though, outdated deps were to blame.
I have opened tickets against combine and rustfmt
https://github.com/rust-lang/rustfmt/issues/5859https://github.com/Marwes/combine/issues/357
should we just remove the other failing repos? :/
changelog: fix integration tests on ci
[`slow_vector_initialization`]: catch `Vec::new()` followed by `.resize(len, 0)`
Closes#10938
changelog: [`slow_vector_initialization`]: catch `Vec::new()` followed by `.resize(len, 0)`
Remove Gha status emitter in compile-test
Disables the github specific output for now since it can be a bit confusing - https://github.com/oli-obk/ui_test/issues/109, in particular the truncation/repetition
r? `@flip1995`
changelog: none
New lint [`needless_return_with_try`]
Closes#10902
Rather than having a config option, this will just suggest removing the "return"; if `try_err` is used as well, then it'll be added again but without the `?`.
changelog: New lint [`needless_return_with_try`]
ptr_arg should ignore extern functions
Fixes: #11181
changelog: [`ptr_arg`]: ignore extern functions that are not
I am not sure whether we should ignore other Rust calling conventions like `rust-intrinsic`, `rust-call` or `rust-cold`.
`unwrap_or_else_default` -> `unwrap_or_default` and improve resulting lint
Resolves#10080 (though it doesn't implement exactly what's described there)
This PR does the following:
1. Merges `unwrap_or_else_default.rs`'s code into `or_fun_call.rs`
2. Extracts the code to handle `unwrap_or(/* default value */)` and similar, and moves it into `unwrap_or_else_default`
3. Implements the missing functionality from #9342, e.g.,, to handle `or_insert_with(Default::default)`
4. Renames `unwrap_or_else_default` to `unwrap_or_default` (since the "new" lint handles both `unwrap_or` and `unwrap_or_else`, it seemed sensible to use the shortened name)
This PR is currently two commits. The first implements 1-3, the second implements 4.
A word about 2: the `or_fun_call` lint currently produces warnings like the following:
```
error: use of `unwrap_or` followed by a call to `new`
--> $DIR/or_fun_call.rs:56:14
|
LL | with_new.unwrap_or(Vec::new());
| ^^^^^^^^^^^^^^^^^^^^^ help: try: `unwrap_or_default()`
```
To me, such warnings look like they should come from `unwrap_or_else_default`, not `or_fun_call`, especially since `or_fun_call` is [in the nursery](https://github.com/rust-lang/rust-clippy/pull/9829).
---
changelog: Move: Renamed `unwrap_or_else_default` to [`unwrap_or_default`]
[#10120](https://github.com/rust-lang/rust-clippy/pull/10120)
changelog: Enhancement: [`unwrap_or_default`]: Now handles more functions, like `or_insert_with`
[#10120](https://github.com/rust-lang/rust-clippy/pull/10120)
<!-- changelog_checked-->
check that the types are equal in `SpanlessEq::eq_expr`
Fixes#11213
changelog: [`if_same_then_else`]: don't lint for integer literals of different types
Fix async functions handling for `needless_pass_by_ref_mut` lint
Fixes https://github.com/rust-lang/rust-clippy/issues/11179.
The problem with async is that "internals" are actually inside a closure from the `ExprUseVisitor` point of view, meaning we need to actually run the check on the closures' body as well.
changelog: none
r? `@llogiq`
Make `comparison_to_empty` work on `if let`/`let` chains
This adds `LetChain` to `clippy_utils::higher`, other lints may benefit from such a change as well :D
changelog: Enhancement: [`comparison_to_empty`]: Now lints on `if let`
[`unused_async`]: don't lint if paths reference async fn without immediate call
Fixes#9695Fixes#9359
Clippy shouldn't lint unused `async` if there are paths referencing them if that path isn't the receiver of a function call, because that means that the function might be passed to some other function:
```rs
async fn f() {} // No await statements, so unused at this point
fn requires_fn_future<F: Future<Output = ()>>(_: fn() -> F) {}
requires_fn_future(f); // `f`'s asyncness is actually not unused.
```
(This isn't limited to just passing the function as a parameter to another function, it could also first be stored in a variable and later passed to another function as an argument)
This requires delaying the linting until post-crate and collecting path references to local async functions along the way.
changelog: [`unused_async`]: don't lint if paths reference async fn that require asyncness
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
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)`
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.
[`unnecessary_literal_unwrap`]: Fix ICE on None.unwrap_or_default()
Fixes#11099Fixes#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()`
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.
[`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)
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
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
Rewrite [`tuple_array_conversions`]
Fixes#11100Fixes#11144Fixes#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
Add `imports_granularity = "Module"` to rustfmt.toml
This lets rustfmt split/merge imports, `Module` seems to be the most common style in clippy
https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#imports_granularity
changelog: none
Almost all the updates other than the config file change are from `cargo dev fmt` or blessed tests, the exceptions being
- `tests/ui/single_component_path_imports.rs`
- `tests/ui/single_component_path_imports_nested_first.rs`
- `tests/ui/single_component_path_imports_self_after.rs`
- `tests/ui/single_component_path_imports_self_before.rs`
- `tests/ui/unsafe_removed_from_name.rs` (added a test with merged imports as a drive by)
- `tests/ui/wildcard_imports.rs`
- `tests/ui/wildcard_imports_2021.rs`
[`arithmetic_side_effect`]: allow different types on the right hand side for `Wrapping<T>`
Fixes#11145
This lint has a list of allowed types, one of which is `Wrapping<T>`, but it was only actually allowed if the type on the right hand side was also `Wrapping<T>`, which meant that, for example, `Wrapping<u32> += u32` would still lint. It now allows binary ops involving `Wrapping<T>` regardless of the type on the rhs.
These impls have only existed since Rust 1.60.0, so that is probably why the lint was previously not handling this correctly
changelog: [`arithmetic_side_effect`]: allow different types on the right hand side for `Wrapping<T>` (e.g. `Wrapping<T> += T`)
[`unnecessary_literal_unwrap`]: also lint `unwrap_(err_)unchecked`
Closes#11093
changelog: [`unnecessary_literal_unwrap`]: also lint `unwrap_unchecked` and `unwrap_err_unchecked`
Use depinfo to discover UI test dependencies
changelog: none
context: https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Building.20test.20dependencies
This restores [the old `EXTERN_FLAGS` method](4cf5bdc60c/tests/compile-test.rs (L67-L75)) of passing `--extern` flags for building UI tests with minor changes
- Unused deps were removed
- It's now a `Vec` of args instead of a command string
- It uses a `BTreeMap` so the extern flags are in alphabetical order and deterministic
I don't know if the `HOST_LIBS` part is still required, but I figured it best to leave it in for now. If the change is accepted we can take a look if it's needed in `rust-lang/rust` after the next sync
This isn't as pleasant as having a `Cargo.toml`, though there is something satisfying about knowing the dependencies are already built and not needing to invoke `cargo`
r? `@flip1995`
This commit fixes#11025 by removing checks for `todo!`,
`unimplemented!` and `unreachable!`.
Signed-off-by: Panagiotis Foliadis <pfoliadis@hotmail.com>
Uplift `clippy::fn_null_check` lint
This PR aims at uplifting the `clippy::fn_null_check` lint into rustc.
## `incorrect_fn_null_checks`
(warn-by-default)
The `incorrect_fn_null_checks` lint checks for expression that checks if a function pointer is null.
### Example
```rust
let fn_ptr: fn() = /* somehow obtained nullable function pointer */
if (fn_ptr as *const ()).is_null() { /* ... */ }
```
### Explanation
Function pointers are assumed to be non-null, checking for their nullity is incorrect.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
[`unnecessary_literal_unwrap`]: don't lint if binding initializer comes from expansion
Fixes https://github.com/rust-lang/rust-clippy/discussions/11109
changelog: [`unnecessary_literal_unwrap`]: don't lint if binding initializer comes from expansion
"try this" -> "try"
Current help messages contain a mix of "try", "try this", and one "try this instead". In the spirit of #10631, this PR adopts the first, as it is the most concise.
It also updates the `lint_message_conventions` test to catch cases of "try this".
(Aside: #10120 unfairly contained multiple changes in one PR. I am trying to break that PR up into smaller pieces.)
changelog: Make help messages more concise ("try this" -> "try").
Add `needless_pass_by_ref_mut` lint
changelog: [`needless_pass_by_ref_mut`]: This PR add a new lint `needless_pass_by_ref_mut` which emits a warning in case a `&mut` function argument isn't used mutably. It doesn't warn on trait and trait impls functions.
Fixes#8863.
cargo dev fmt
cargo test passes
cargo test passes
refactor a lil
Update bool_comparison.stderr
heavily refactor + bump `clippy::version`
refactor
refactor
check bounds to increase accuracy, and add todos
new lint: `read_line_without_trim`
This adds a new lint that checks for calls to `Stdin::read_line` with a reference to a string that is then attempted to parse into an integer type without first trimming it, which is always going to fail at runtime.
This is something that I've seen happen a lot to beginners, because it's easy to run into when following the example of chapter 2 in the book where it shows how to program a guessing game.
It would be nice if we could point beginners to clippy and tell them "let's see what clippy has to say" and have clippy explain to them why it fails 👀
I think this lint can later be "generalized" to work not just for `Stdin` but also any `BufRead` (which seems to be where the guarantee about the trailing newline comes from) and also, matching/comparing it to a string slice that doesn't end in a newline character (e.g. `input == "foo"` is always going to fail)
changelog: new lint: [`read_line_without_trim`]
[`useless_vec`]: add more tests and don't lint inside of macros
Closes#11084.
I realized that the fix I added in #11081 itself also causes an error in a suggestion when inside of a macro. Example:
```rs
macro_rules! x {
() => {
for _ in vec![1, 2] {}
}
}
x!();
```
Here it would suggest replacing `vec![1, 2]` with `[x!()]`, because that's what the source callsite is (reminder: it does this to get the correct span of `x!()` for code like `for _ in vec![x!()]`), but that's wrong when *inside* macros, so I decided to make it not lint if the whole loop construct is inside a macro to avoid this issue.
changelog: [`useless_vec`]: add more tests and don't lint inside of macros
r? `@Alexendoo` since these were your tests, I figured it makes most sense to assign you
Don't lint manual_let_else in cases where ? would work
Don't lint `manual_let_else` where the question mark operator `?` would be sufficient, that is, mostly in cases like:
```Rust
let v = if let Some(v) = ex { v } else { return None };
```
Also, this PR emits the `question_mark` lint for `let...else` patterns that could be written with `?` (also, only `return None` like cases).
```
changelog: [`manual_let_else`]: don't lint in cases where question_mark already lints
changelog: [`question_mark`]: lint for `let Some(...) = ex else { return None };`
```
Fixes #8755
[`useless_vec`]: use the source span for initializer
Fixes#11075.
changelog: [`useless_vec`]: use the source span for the initializer expression when inside of a macro
[`arc_with_non_send_sync`]: don't lint if type has nested type parameters
Fixes#11076
changelog: [`arc_with_non_send_sync`]: don't lint if type has nested type parameters
r? `@Manishearth`
new lint: `type_id_on_box`
Closes#7687.
A new lint that detects calling `.type_id()` on `Box<dyn Any>` (and not on the underlying `dyn Any`), which can make up for some pretty confusing bugs!
changelog: new lint: [`type_id_on_box`]
Add `SPEEDTEST`
In the `master` branch, we currently don't have any way to test the performance of a single lint in changes.
This PR adds `SPEEDTEST`, the environment variable which lets you do a speed test on a lint / category of tests with various configuration options.
Maybe we should merge this with `lintcheck` 🤔
See the book page for more information.
changelog:none
`let_and_return`: lint 'static lifetimes, don't lint borrows in closures
Fixes#11056
Now also ignores functions returning `'static` lifetimes, since I noticed the `stdin.lock()` example was still being linted but doesn't need to be since https://github.com/rust-lang/rust/pull/93965
changelog: none
New lint [`tuple_array_conversions`]
Closes#10748
PS, the implementation is a bit ugly 😅 ~~I will likely refactor soon enough :)~~ Done :D
changelog: New lint [`tuple_array_conversions`]
Also, lint question_mark for `let...else` clauses that can be simplified to use `?`.
This lint isn't perfect as it doesn't support the unstable try blocks.
[significant_drop_tightening] Fix#10413Fix#10413
This is quite a rewrite that unfortunately took a large amount of time. I tried my best to comment what is going on to easy review but feel free to ask any question.
The problem basically is that the current algorithm is only taking into consideration single blocks which means that things like the following don't work or show unpredictable results.
```rust
let mutex = Mutex::new(1);
{
let lock = mutex.lock().unwrap();
{
let _ = *lock;
}
}
```
The solve the issue, each path that refers a lock is now being tracked individually.
```
changelog: [`significant_drop_tightening`]: Lift the restriction of only considerate single blocks
```
New lint [`redundant_at_rest_pattern`]
Closes#11011
It's always a great feeling when a new lint triggers on clippy itself 😄
changelog: New lint [`redundant_at_rest_pattern`]
suggests `is_some_and` over `map().unwrap`
changelog: Enhancement: [`option_map_unwrap_or`] now considers the [`msrv`] config when creating the suggestion.
* modified option_map_unwrap_or lint to recognise when an `Option<T>` is mapped to an `Option<bool>` with false being used when `None` is detected; suggests the use of `is_some_and` instead
* msrv is set to 1.70.0 for this lint; when `is_some_and` was stabilised
fixes#9125
[`question_mark`]: don't lint inside of `try` block
Fixes#8628.
Diff looks a bit noisy because I had to move the two functions into an impl, because they now need to access the structs `try_block_depth` field to see if they're inside a try block.
changelog: [`question_mark`]: don't lint inside of `try` block
[`option_if_let_else`]: suggest `.as_ref()` if scrutinee is of type `&Option<_>`
Fixes#10729
`Option::map_or` takes ownership, so if matching on an `&Option<_>`, we need to suggest `.as_ref()` before calling `map_or` to get the same effect and to not cause a borrowck error.
changelog: [`option_if_let_else`]: suggest `.as_ref()`/`.as_mut()` if scrutinee is of type `&Option<_>`/`&mut Option<_>`
[`unused_async`]: don't lint if function is part of a trait
Fixes#10459.
We shouldn't lint if the function is part of a trait, because the user won't be able to easily remove the `async`, as this will then not match with the function signature in the trait definition
changelog: [`unused_async`]: don't lint if function is part of a trait
Use substring matching for TESTNAME
Restores the previous behaviour of matching using a substring match rather than needing a full match
changelog: none
Add `BLESS` for compile-test and some cleanup
changelog: none
Allows passing the environment variable `BLESS` to bless tests, which is useful when you want to bless internal tests - `BLESS= cargo uitest -Finternal`
Also updates a place in the docs referring to `cargo dev bless` and removes some unused test deps
Port clippy away from compiletest to ui_test
Reasons to do this:
* runs completely on stable Rust
* is easier to extend with new features
* has its own dogfood test suite, so changes can be tested in [the `ui_test` repo](https://github.com/oli-obk/ui_test)
* supports dependencies from crates.io without having to manually fiddle with command line flags
* supports `ui-cargo`, `ui`, `ui-toml` out of the box, no need to find and run the tests ourselves
One thing that is a big difference to `compiletest` is that if a test emits *any* error, you need to mark all of them with `//~ ERROR:` annotations. Since many clippy tests did not have annotations, I changed many lints to be `warn` in their test so that only the `stderr` output is tested.
TODO:
* [ ] check that this still works as a subtree in the rustc repo
changelog: none
<!-- changelog_checked -->
Note: at present the latest changes needed for clippy are only available as a git dependency, but I expect to publish a new crates.io version soon
Check if `if` conditions always evaluate to true in `never_loop`
This fixes the example provided in #11004, but it shouldn't be closed as this is still an issue on like
```rust
let x = true;
if x { /* etc */ }`
```
This also makes `clippy_utils::consts::constant` handle `ConstBlock` and `DropTemps`.
changelog: [`never_loop`]: Check if `if` conditions always evaluate to true
Lint `mem_forget` if any fields are `Drop`
Closes#9298
I think this way of doing it (`needs_drop`) should be fine.
---
changelog: Enhancement: [`mem_forget`]: Now lints on types with fields that implement `Drop`
[#10996](https://github.com/rust-lang/rust-clippy/pull/10996)
[`format_push_string`]: look through `match` and `if` expressions
Closes#9493.
changelog: [`format_push_string`]: look through `match` and `if` expressions
[`get_unwrap`]: include a borrow in the suggestion if argument is not an integer literal
Fixes#9909
I have to say, I don't really understand what the previous logic was trying to do, but this fixes the linked bug.
It was checking if the argument passed to `.get()` can be parsed as a usize (i.e. if it's an integer literal, probably?), and if not, it wouldn't include a borrow? I don't know how we came to that conclusion, but that logic doesn't work:
```rs
let slice = &[1, 2];
let _r: &i32 = slice.get({ 1 }).unwrap();
// previous suggestion: slice[{ 1 }]
// the suggestion should be: &slice[{ 1 }]
```
Here the argument passed to it isn't an integer literal, but it should still include a borrow, because it would otherwise change the type from `&i32` to `i32`.
The exception is that if the parent of the `get().unwrap()` expr is a dereference or a method call or the like, we don't need an explicit borrow because it's automatically inserted by the compiler
changelog: [`get_unwrap`]: include a borrow in the suggestion if argument is not an integer literal
Don't lint [`iter_nth_zero`] in `next`
Closes#9820
This also *slightlyy* modifies the output of `iter_nth`, as I noticed the types' names weren't in backticks
changelog: [`iter_nth_zero`]: No longer lints in implementations of `Iterator::next`
[`single_match`]: don't lint if block contains comments
Fixes#8634
It now ignores matches with a comment in the "else" arm
changelog: [`single_match`]: don't lint if block contains comments
[`redundant_closure_call`]: handle nested closures
Fixes#9956.
This ended up being a much larger change than I'd thought, and I ended up having to pretty much rewrite it as a late lint pass, because it needs access to certain things that I don't think are available in early lint passes (e.g. getting the parent expr). I think this'll be required to fi-x #10922 anyway, so this is probably fine.
(edit: had to write "fi-x" because "fix" makes github think that this PR fixes it, which it doesn't 😅 )
Previously, it would suggest changing `(|| || 42)()()` to `|| 42()`, which is a type error (it needs parens: `(|| 42)()`). In my opinion, though, the suggested fix should have really been `42`, so that's what this PR changes.
changelog: [`redundant_closure_call`]: handle nested closures and rewrite as a late lint pass
Fix false positive of [self_named_module_files] and [mod_module_files]
changelog: [self_named_module_files] [mod_module_files]: No longer lints dependencies located in subdirectory of workspace
fixes#8887
---
First time contributor here, just read contribution guide today.
I have several questions:
1. ~Is it the correct way to use environment variable `CARGO_HOME` to get the location of cargo home directory?~
(Edit: Code no longer uses CARGO_HOME)
2. How to setup test for this PR? This involves multiple files and `CARGO_HOME` setup. ~Not sure how to do this.~
~Edit: Working on tests right now~ A workspace_test has been added
[`arithmetic_side_effects`] Fix#10792Fix#10792
```
changelog: [`arithmetic_side_effects`]: Retrieve field values of structures that are in constant environments
```
Ignore more type aliases in `unnecessary_cast`
This is potentially the worst code I've ever written, and even if not, it's very close to being on par with starb. This will ignore `call() as i32` and `local_obtained_from_call as i32` now.
This should fix every reasonable way to reproduce #10555, but likely not entirely.
changelog: Ignore more type aliases in `unnecessary_cast`
[`missing_panics_doc`]: pickup expect method
close#10240
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: [`missing_panics_doc`]: pickup expect method
new lint: `drain_collect`
Closes#10818.
This adds a new lint that looks for `.drain(..).collect()` and suggests replacing it with `mem::take`.
changelog: [`drain_collect`]: new lint
[`match_same_arms`]: don't lint if `non_exhaustive_omitted_patterns`
Fixes#10327
changelog: [`match_same_arms`]: Don't lint if `non_exhaustive_omitted_patterns` is `warn` or `deny`
from_over_into: Show suggestions for non-Self expanded paths
changelog: [`from_over_into`]: Show suggestions when the body contains macros not expanding to `Self`
Currently any path in a macro expansion causes the suggestion to be hidden, meaning most macro calls cause it to be hidden
Now it's only hidden if the expansion contains `Self`
[`unnecessary_fold`]: suggest turbofish if necessary
Fixes#10000
This adds turbofish `::<T>` to the suggestion in `unnecessary_fold`. This is necessary because the `Sum` trait is generic, which breaks inference when changing `fold()` to `sum()`.
changelog: [`unnecessary_fold`]: suggest turbofish if necessary
new lint [`single_range_in_vec_init`]
Lints on `vec![0..200]` (or `[0..200]`), suggesting either `(0..200).collect::<Vec<i32>>()` or `[0; 200]`.
Haven't tested it with anything that isn't primitive. Probably should!
Closes#10932
changelog: new lint [`single_range_in_vec_init`]
[`derivable_impls`]: don't lint if `default()` call expr unsize-coerces to trait object
Fixes#10158.
This fixes a FP where the derive-generated Default impl would have different behavior because of unsize coercion from `Box<T>` to `Box<dyn Trait>`:
```rs
struct S {
x: Box<dyn std::fmt::Debug>
}
impl Default for S {
fn default() -> Self {
Self {
x: Box::<()>::default()
// ^~ Box<()> coerces to Box<dyn Debug>
// #[derive(Default)] would call Box::<dyn Debug>::default()
}
}
}
```
(this intentionally only looks for trait objects `dyn` specifically, and not any unsize coercion, e.g. `&[i32; 5]` to `&[i32]`, because that breaks existing tests and isn't actually problematic, as far as I can tell)
changelog: [`derivable_impls`]: don't lint if `default()` call expression unsize-coerces to trait object
[`needless_doctest_main`]: ignore `main()` in `no_test` code fences
close#10491
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: [`needless_doctest_main`]: ignore `main()` in `no_test` code fence
[`map_unwrap_or`]: don't lint when referenced variable is moved
Fixes#10579.
The previous way of checking if changing `map(f).unwrap_or(a)` to `map_or(a, f)` is safe had a flaw when the argument to `unwrap_or` moves a binding and the `map` closure references that binding in some way.
It used to simply check if any of the identifiers in the `unwrap_or` argument are referenced in the `map` closure, but it didn't consider the case where the moved binding is referred to through references, for example:
```rs
let x = vec![1, 2];
let x_ref = &x;
Some(()).map(|_| x_ref.clone()).unwrap_or(x);
```
This compiles as is, but we cannot change it to `map_or`. This lint however did suggest changing it, because the simple way of checking if `x` is referenced anywhere in the `map` closure fails here. The safest thing to do here imo (what this PR does) is check if the moved value `x` is referenced *anywhere* in the body (before the `unwrap_or` call). One can always create a reference to the value and smuggle them into the closure, without actually referring to `x`. The original, linked issue shows another one such example:
```rs
let x = vec![1,2,3,0];
let y = x.strip_suffix(&[0]).map(|s| s.to_vec()).unwrap_or(x);
```
`x.strip_suffix(&[0])` creates a reference to `x` that is available through `s` inside of the `map` closure, so we can't change it to `map_or`.
changelog: [`map_unwrap_or`]: don't lint when referenced variable is moved
[`no_effect`]: Suggest adding `return` if applicable
Closes#10941
Unfortunately doesn't catch anything complex as `no_effect` already wouldn't, but I'm fine with that (it catches `ControlFlow` at least :D)
changelog: [`no_effect`]: Suggest adding `return` if statement has same type as function's return type and is the last statement in a block
Improve suggestion for [`needless_lifetimes`]
Fixes#10093
changelog: [`needless_lifetimes`]: Suggestion now points at the elidable lifetimes, rather than the entire function declaration
[`missing_const_for_fn`]: Ensure dropped locals are `~const Destruct`
this will check every local for `TerminatorKind::Drop` to ensure they can be evaluated at compile time, not sure if this is the best way to do this but MIR is confusing and it works so...
fixes#10617
changelog: [`missing_const_for_fn`]: Ensure dropped locals are `~const Destruct`
[`useless_vec`]: lint on `vec![_]` invocations that adjust to a slice
Fixes#2262 (well, actually my PR over at #10901 did do most of the stuff, but this PR implements the one last other case mentioned in the comments that my PR didn't fix)
Before this change, it would lint `(&vec![1]).iter().sum::<i32>()`, but not `vec![1].iter().sum::<i32>()`. This PR handles this case.
This also refactors a few things that I wanted to do in my other PR but forgot about.
changelog: [`useless_vec`]: lint on `vec![_]` invocations that adjust to a slice
Don't linting `as_conversions` in proc macros
Don't linting `as_conversions` if code was generated by procedural macro.
This PR fixes https://github.com/rust-lang/rust-clippy/issues/9657
I implemented the fix changing the lint code to be a `LateLintPass` in order to be able to use the `is_from_proc_macro` out of the box. If the reviwer thinks that it would be better to do the other way (implementing `WithSearchPat`) just let me know. I might need some help in implementing it for the `ustc_ast::ast::Expr`
changelog: [`as_conversions`] avoiding warnings in macro-generated code
Extend `explicit_iter_loop` and `explicit_into_iter_loop`
fixes#1518
Some included cleanups
* Split `for_loop` test into different files for each lint (partially).
* Move handling of some `into_iter` cases from `explicit_into_iter`.
---
changelog: Enhancement: [`explicit_iter_loop`]: Now also handles types that implement `IntoIterator`.
[#10416](https://github.com/rust-lang/rust-clippy/pull/10416)
changelog: Sugg: [`explicit_into_iter_loop`]: The suggestion now works on mutable references.
[#10416](https://github.com/rust-lang/rust-clippy/pull/10416)
<!-- changelog_checked -->
Add `needless_if` lint
first off: Sorry about the large diff. Seems a ton of tests do this (understandably so).
this is basically everything I wanted in #10868, while it doesn't lint *all* unnecessary empty blocks, it lints needless if statements; which are basically the crux of the issue (for me) anyway. I've committed code that includes this far too many times 😅 hopefully clippy can help me out soon
closes#10868
changelog: New lint [`needless_if`]
handle exponent without digits in `numeric_literal`
Fixes#10912
The numeric literal util module didn't check for exponents with no digits.
So:
384cf37612/clippy_utils/src/numeric_literal.rs (L163-L168)
`exponent` here would be the empty string, which passed the `!= "0"` check (when it shouldn't have, it should probably be treated as if the user wrote `E0`), then later fails when counting the digits and subtracting one (0 - 1 = overflow).
Also, interestingly I can't even write a test for this because exponents with no digits is some kind of error by itself and `cargo dev fmt` fails on it.
changelog: [`unreadable_literal`]: don't (debug) ICE on numeric literal with empty exponent
Fix `diverging_sub_expression` not checking body of block
Fixes#10776
This also adds a warning to the test `ui/never_loop.rs`, not sure if this is correct or not.
changelog: [`diverging_sub_expression`]: Fix false negatives with body of block
[`unnecessary_to_owned`]: check that the adjusted type matches target
Fixes#10033.
Before this change, the lint would assume that removing the `.to_string()` in `f(&x.to_string())` would be ok if x is of some type that implements `Deref<Target = str>` and `f` takes a `&str`.
This turns out to not actually be ok if the `to_string` call is some method that exists on `x` directly, which happens if it implements `Display`/`ToString` itself.
changelog: [`unnecessary_to_owned`]: only lint if the adjusted receiver type actually matches
Ignore more pointer types in `unnecessary_cast`
Spotted this because
e2c655b4c0/tests/ui/suspicious_to_owned.rs (L9-L10)
currently fails on `aarch64-unknown-linux-gnu` as `c_char` is `u8` there
The current implementation checks for `as alias`, `as _`. This adds things like
- `as *const alias`
- `as *const cfg_dependant`
- `as *const _`
changelog: none
[`redundant_closure`]: special case inclusive ranges
Fixes#10684.
`x..=y` ranges need a bit of special handling in this lint because it desugars to a call to the lang item `RangeInclusiveNew`, where the callee span would be the same as the range expression itself, so the suggestion looked a bit weird. It now correctly suggests `RangeInclusive::new`.
changelog: [`redundant_closure`]: special case `RangeInclusive`
Adds new lint `arc_with_non_send_or_sync`
Fixes#653
Adds a new lint to check for uses of non-Send/Sync types within Arc.
```
changelog: [`arc_with_non_send_sync`]: Added a lint to detect uses of non-Send/Sync types within Arc.
```
[`useless_vec`]: lint `vec!` invocations when a slice or an array would do
First off, sorry for that large diff in tests. *A lot* of tests seem to trigger the lint with this new change, so I decided to `#![allow()]` the lint in the affected tests to make reviewing this easier, and also split the commits up so that the first commit is the actual logic of the lint and the second commit contains all the test changes. The stuff that changed in the tests is mostly just line numbers now. So, as large as the diff looks, it's not actually that bad. 😅
I manually went through all of these to find out about edge cases and decided to put them in `tests/ui/vec.rs`.
For more context, I wrote about the idea of this PR here: https://github.com/rust-lang/rust-clippy/issues/2262#issuecomment-1579155257 (that explains the logic)
Basically, it now also considers the case where a `Vec` is put in a local variable and the user only ever does things with it that one could also do with a slice or an array. This should catch a lot more cases, and (at least from looking at the tests) it does.
changelog: [`useless_vec`]: lint `vec!` invocations when a slice or an array would do (also considering local variables now)
`suspicious_else_formatting`: Don't warn if there is a comment between else and curly bracket
This PR fixes https://github.com/rust-lang/rust-clippy/issues/10273
The idea is that if the only thing after `else` and before `{` is a comment, we will not warn because, probably, the line break was "made" by rustfmt.
changelog: [`suspicious_else_formatting`]: Don't warn if the only thing between `else` and curly bracket is a comment
consider autoderef through user-defined `Deref` in `eager_or_lazy`
Fixes#10462
This PR handles autoderef in the `eager_or_lazy` util module and stops suggesting to change lazy to eager if autoderef in an expression goes through user defined `Deref` impls, e.g.
```rs
struct S;
impl Deref for S {
type Target = ();
fn deref(&self) -> &Self::Target { &() }
}
let _ = Some(()).as_ref().unwrap_or_else(|| &S); // autoderef `&S` -> `&()`
```
changelog: [`unnecessary_lazy_evaluations`]: don't suggest changing lazy evaluation to eager if autoderef goes through user-defined `Deref`
r? `@xFrednet` (because of the earlier review in #10864, might help for context here)
[`let_with_type_underscore`]: Don't emit on locals from procedural macros
closes#10498
changelog: [`let_with_type_underscore`]: Don't emit on locals from procedural macros
make cast_possible_wrap work correctly for 16 bit {u,i}size
These changes make `cast_possible_wrap` aware of the different pointer widths and fixes the implementation to print the correct pointer widths.
Fixes#9337
changelog: `cast_possible_wrap` does not lint on `u8 as isize` or `usize as i8`, since these can never wrap.
`cast_possible_wrap` now properly considers 16 bit pointer size and prints the correct bit widths.
Add redundant type annotations lint
Hello, I'm trying to add the `redundat_type_annotations` lint.
It's still WIP but I'd like to start gathering some feedbacks to be sure that I'm not doing things 100% wrong :)
Right now it still misses lints like:
- [x] `let foo: u32 = 5_u32`,
- [x] `let foo: String = STest2::func()`
- [x] `let foo: String = self.func()` (`MethodCall`)
- [x] refs
- [ ] Generics
I've some problems regarding the second example above, in the `init` part of the `Local` I have:
```rust
init: Some(
Expr {
hir_id: HirId(DefId(0:24 ~ playground[e1bd]::main).58),
kind: Call(
Expr {
hir_id: HirId(DefId(0:24 ~ playground[e1bd]::main).59),
kind: Path(
TypeRelative(
Ty {
hir_id: HirId(DefId(0:24 ~ playground[e1bd]::main).61),
kind: Path(
Resolved(
None,
Path {
span: src/main.rs:77:21: 77:27 (#0),
res: Def(
Struct,
DefId(0:17 ~ playground[e1bd]::STest2),
),
segments: [
PathSegment {
ident: STest2#0,
hir_id: HirId(DefId(0:24 ~ playground[e1bd]::main).60),
res: Def(
Struct,
DefId(0:17 ~ playground[e1bd]::STest2),
),
args: None,
infer_args: true,
},
],
},
),
),
span: src/main.rs:77:21: 77:27 (#0),
},
PathSegment {
ident: get_numb#0,
hir_id: HirId(DefId(0:24 ~ playground[e1bd]::main).62),
res: Err,
args: None,
infer_args: true,
},
),
),
span: src/main.rs:77:21: 77:37 (#0),
},
[],
),
span: src/main.rs:77:21: 77:39 (#0),
},
),
```
And I'm not sure how to get the return type of the function `STest2::func()` since the resolved path `DefId` points to the struct itself and not the function. Do you have any idea on how I could get this information in this case?
Thanks!
changelog: changelog: [`redundant_type_annotations`]: New lint to warn on redundant type annotations
fixes#9155
[`unnecessary_lazy_eval`]: don't lint on types with deref impl
Fixes#10437.
This PR changes clippy's util module `eager_or_lazy` to also consider deref expressions whose type has a non-builtin deref impl and not suggest replacing it as that might have observable side effects.
A prominent example might be the `lazy_static` macro, which creates a newtype with a `Deref` impl that you need to go through to get access to the inner value. Going from lazy to eager can make a difference there.
changelog: [`unnecessary_lazy_eval`]: don't lint on types with non-builtin deref impl
Add lints for disallowing usage of `to_xx_bytes` and `from_xx_bytes`
Adds `host_endian_bytes`, `little_endian_bytes` and `big_endian_bytes`
Closes#10765
v - not sure what to put here since this adds 3 lints
changelog: Add `host_endian_bytes`, `little_endian_bytes` and `big_endian_bytes` lints
[`allow_attributes`, `allow_attributes_without_reason`]: Ignore attributes from procedural macros
I use `lint_reasons` and `clap`, which is a bit overzealous when it comes to preventing warnings in its macros; it uses a ton of allow attributes on everything to, as ironic as it is, silence warnings. These two now ignore anything from procedural macros.
PS, I think `allow_attributes.rs` should be merged with `attrs.rs` in the future.
fixes#10377
changelog: [`allow_attributes`, `allow_attributes_without_reason`]: Ignore attributes from procedural macros
Ignore fix for `from_over_into` if the target type contains a `Self` reference
Fixes https://github.com/rust-lang/rust-clippy/issues/10838.
This is my first time contributing here, and the fix is kind of ugly.
I've worked a bit with `quote` and was trying to figure out a way to replace the type in a better way than just a raw string-replace but couldn't quite figure out how to.
The only thing really required to fix this, is to replace all `Self` references with the type stated in the `from` variable, this isn't entirely simple to do with raw strings without creating a mess though.
We need to find and replace all `Self`'s in a variable with `from` but there could be an arbitrary amount, in a lot of different positions. As well as some type that contains the name self, like `SelfVarSelf` which shouldn't be replaced.
The strategy is essentially, if `"Self"` is surrounded on both sides by something that isn't alphanumeric, then we're golden, then trying to make that reasonably efficient.
I would not be offended if the solution is too messy to accept!
changelog: [from_over_into]: Replace Self with the indicated variable in suggestion and fix.
new lint: `explicit_into_iter_fn_arg`
Closes#10743.
This adds a lint that looks for `.into_iter()` calls in a call expression to a function that already expects an `IntoIterator`. In those cases, explicitly calling `.into_iter()` is unnecessary.
There were a few instances of this in clippy itself so I fixed those as well in this PR.
changelog: new lint [`explicit_into_iter_fn_arg`]
manual_let_else: support struct patterns
This adds upon the improvements of #10797 and:
* Only prints `()` around `Or` patterns at the top level (fixing a regression of #10797)
* Supports multi-binding patterns: `let (u, v) = if let (Some(u_i), Ok(v_i)) = ex { (u_i, v_i) } else ...`
* Traverses through tuple patterns: `let v = if let (Some(v), None) = ex { v } else ...`
* Supports struct patterns: `let v = if let S { v, w, } = ex { (v, w) } else ...`
```
changelog: [`manual_let_else`]: improve pattern printing to support struct patterns
```
fixes#10708fixes#10424
[`ptr_cast_constness`]: Only lint on casts which don't change type
fixes#10874
changelog: [`ptr_cast_constness`]: Only lint on casts which don't change type
Emit `unnecessary_cast` on raw pointers as well
Supersedes(?) #10782, since this and #10567 will cover the original issue.
Does not lint on type aliases or inferred types.
changelog: [`unnecessary_cast`]: Also emit on casts between raw pointers with the same type and constness
add checking for cfg(features = ...)
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: [`maybe_misused_cfg`]: check if `#[cfg(feature = "...")]` misused as `#[cfg(features = "...")]`
I've found that there is no indication when `#[cfg(features = "...")]` is used incorrectly, which can easily make mistakes hard to spot. When I searched for this code on github, I also found many misuse cases([link](https://github.com/search?q=%23%5Bcfg%28features+language%3ARust&type=code)).
PS: This clippy name is just a temporary name, it can be replaced with a better name.
Add spans to `clippy.toml` error messages
Adds spans to errors and warnings encountered when parsing `clippy.toml`.
changelog: Errors and warnings generated when parsing `clippy.toml` now point to the location in the TOML file the error/warning occurred.
move some strings into consts, more tests
s/missing_field_in_debug/missing_fields_in_debug
dont trigger in macro expansions
make dogfood tests happy
minor cleanups
replace HashSet with FxHashSet
replace match_def_path with match_type
if_chain -> let chains, fix markdown, allow newtype pattern
fmt
consider string literal in `.field()` calls as used
don't intern defined symbol, remove mentions of 'debug_tuple'
special-case PD, account for field access through `Deref`
Improve pattern printing for manual_let_else
* Address a formatting issue pointed out in https://github.com/rust-lang/rust-clippy/pull/10175/files#r1137091002
* Replace variables inside | patterns in the if let: `let v = if let V::A(v) | V::B(v) = v { v } else ...`
* Support nested patterns: `let v = if let Ok(Ok(Ok(v))) = v { v } else ...`
* Support tuple structs with more than one arg: `let v = V::W(v, _) = v { v } else ...`; note that more than one *capture* is still not supported, so it bails for `let (v, w) = if let E::F(vi, wi) = x { (vi, wi)}`
* Correctly handle .. in tuple struct patterns: `let v = V::X(v, ..) = v { v } else ...`
- \[ ] Followed [lint naming conventions][lint_naming]
- \[x] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[ ] Executed `cargo dev update_lints`
- \[ ] Added lint documentation
- \[x] Run `cargo dev fmt`
[lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
---
changelog: [`manual_let_else`]: improve variable name in suggestions
Closes#10431 as this PR is adding a test for the `mut` case.
Ignore `#[cfg]`'d out code in `needless_else`
changelog: none (same release as #10810)
`#[cfg]` making things fun once more
This lead me to think about macro calls that expand to nothing as well, but apparently they produce an empty stmt in the AST so are already handled, added a test for that
r? `@llogiq`
[`default_constructed_unit_structs`]: do not lint on type alias paths
Fixes#10755.
Type aliases cannot be used as a constructor, so this lint should not trigger in those cases.
I also changed `clippy_utils::is_ty_alias` to also consider associated types since [they kinda are type aliases too](48ec50ae39/compiler/rustc_resolve/src/late/diagnostics.rs (L1520)).
changelog: [`default_constructed_unit_structs`]: do not lint on type alias paths
[`unused_async`]: do not consider `await` in nested `async` blocks as used
Fixes#10800.
This PR makes sure that `await` expressions inside of inner `async` blocks don't prevent the lint from triggering.
For example
```rs
async fn foo() {
async {
std::future::ready(()).await;
}
}
```
Even though there *is* a `.await` expression in this function, it's contained in an async block, which means that the enclosing function doesn't need to be `async` too.
changelog: [`unused_async`]: do not consider `await` in nested `async` blocks as used
Add new lint `ptr_cast_constness`
This adds a new lint which functions as the opposite side of the coin to `ptr_as_ptr`. Rather than linting only as casts that don't change constness, this lints only constness; suggesting to use `pointer::cast_const` or `pointer::cast_mut` instead.
changelog: new lint [`ptr_cast_constness`]
needless_else: new lint to check for empty `else` clauses
Empty `else` clauses are useless. They happen in the wild and are not linted yet: https://github.com/uutils/coreutils/pull/4880/files
`else` clauses containing or preceded by comments are not linted as the comments might be important.
changelog: [`needless_else`]: new lint
Fix missing block for unsafe code
If a block is declared as unsafe, it needs an extra layer of curly braces around it.
Fixes#10808
This code adds handling for `UnsafeSource::UserProvided` block, i.e. `unsafe { ... }`. Note that we do not handle the `UnsafeSource::CompilerGenerated` as it seems to not be possible to generate that with the user code (?), or at least doesn't seem to be needed to be handled explicitly.
There is an issue with this code: it does not add an extra indentation for the unsafe blocks. I think this is a relatively minor concern for such an edge case, and should probably be done by a separate PR (fixing compile bug is more important than getting styling perfect especially when `rustfmt` will fix it anyway)
```rust
// original code
unsafe {
...
}
// code that is now generated by this PR
{ unsafe {
...
} }
// what we would ideally like to get
{
unsafe {
...
}
}
```
changelog: [`single_match`](https://rust-lang.github.io/rust-clippy/master/#single_match): Fix suggestion for `unsafe` blocks
[`large_stack_arrays`]: check array initializer expressions
Fixes#10741.
Prior to this PR, the lint only checked array repeat expressions (ie. `[T; n]`). Now it also checks array initializer expressions.
changelog: [`large_stack_arrays`]: check array initializer expressions
These unit tests generate non-compilable code. I did NOT `bless` them on purpose because the stderr output is not good.
I'm surprised we don't auto-compile the suggestions here - is this something that can be easily enabled?
See #10808
Enhance `needless_collect`: lint in method/function arguments that take an `IntoIterator`
Updates `needless_collect` to also lint `collect` calls in method/function arguments that take an `IntoIterator` (for example `Extend::extend`). Every `Iterator` trivially implements `IntoIterator` and collecting it only causes an unnecessary allocation.
---
changelog: Enhancement: [`needless_collect`]: Now also detects function arguments, taking a generic `IntoIterator`
[#10777](https://github.com/rust-lang/rust-clippy/pull/10777)
<!-- changelog_checked -->
fixes#10762
* Don't consider expansions of different macros to be the same, even if they expand to the same tokens
* Don't consider `cfg!` expansions to be equal if they check different configs.
* Replace variables inside | patterns in the if let: let v = if let V::A(v) | V::B(v) = v { v } else ...
* Support nested patterns: let v = if let Ok(Ok(Ok(v))) = v { v } else ...
* Support tuple structs with more than one arg: let v = V::W(v, _) = v { v } else ...
* Correctly handle .. in tuple struct patterns: let v = V::X(v, ..) = v { v } else ...
Rename `integer_arithmetic`
The lack of official feedback in #10200 made me give up on pursuing the matter but after yet another use-case that is not handled by `integer_arithmetic` (#10615), I think it is worth trying again.
---
changelog: Move/Deprecation: Rename `integer_arithmetic` to `arithmetic_side_effects`
[#10674](https://github.com/rust-lang/rust-clippy/pull/10674)
<!-- changelog_checked -->
don't remove `dbg!` in arbitrary expressions
Fixes#9914
The `dbg_macro` lint replaces empty `dbg!` invocations with the empty string in its suggestion, which is not always valid code in certain contexts (e.g. `let _ = dbg!();` becomes `let _ = ;`). This PR changes it to `()`, which should always be valid where `dbg!()` is valid (`dbg!()` with no arguments evaluates to `()`).
It also special-cases "standalone" `dbg!();` expression statements, where it will suggest removing the whole statement entirely like it did before.
changelog: [`dbg_macro`]: don't remove `dbg!()` in arbitrary expressions as it sometimes results in syntax errors
fix [`invalid_regex`] not recognizing new syntax introduced after regex-1.8.0
fixes: #10680
---
changelog: fix [`invalid_regex`] not recognizing new syntax introduced after regex-1.8.0
bump up `regex-syntax` dependency version to 0.7.0
Fix: Some suggestions generated by the option_if_let_else lint did not compile
This addresses a bug in Clippy where the fix suggestend by the `option_if_let_else` lint would not compile for `Result`s which have an impure expression in the `else` branch.
---
changelog: [`option_if_let_else`]: Fixed incorrect suggestion for `Result`s
[#10337](https://github.com/rust-lang/rust-clippy/pull/10337)
<!-- changelog_checked -->
Fixes#10335.
Updates `needless_collect` to lint for collecting into a method or
function argument thats taking an `IntoIterator` (for example `extend`).
Every `Iterator` trivially implements `IntoIterator` and colleting it
only causes an unnecessary allocation.
[arithmetic_side_effects] Consider referenced allowed or hard-coded types
Fix#10767
```
changelog: [`arithmetic_side_effects`]: Do not fire when dealing with allowed or hard-coded types that are referenced.
```
fix: warn on empty line outer AttrKind::DocComment
changelog: [`empty_line_after_doc_comments`]: add lint for checking empty lines after rustdoc comments.
Fixes: #10395
Extend `trait_duplication_in_bounds` to cover trait objects
This PR extends `trait_duplication_in_bounds` to cover trait objects.
Currently,
```rs
fn foo(_a: &(dyn Any + Send + Send)) {}
```
generates no warnings. With this PR, it will complain about a duplicate trait and can remove it
Moved from rust-lang/rust#110991
changelog: [`trait_duplication_in_bounds`]: warn on duplicate trait object constraints
fix: `wildcard_imports` ignore `test.rs` files
Adds a check to see if the building crate is a test one, if so, ignore it
---
Closes#10580
changelog:[`wildcard_imports`]: Add a check to ignore files named `test.rs` and `tests.rs`
Ignore `borrow_deref_ref` warnings in code from procedural macros.
Don't linting `borrow_deref_ref` if code was generated by procedural macro.
This PR fixes https://github.com/rust-lang/rust-clippy/issues/8971
changelog: [`borrow_deref_ref`] avoiding warnings in macro-generated code
Fixes#10609: Adds lint to detect construction of unit struct using `default`
Using `default` to construct a unit struct increases code complexity and adds a function call. This can be avoided by simply removing the call to `default` and simply construct by name.
changelog: [`default_constructed_unit_structs`]: detects construction of unit structs using `default`
fixes#10609
Fix `items_after_test_module`: Ignore imported modules
Fixes#10713. It does a little bit of dark magic, but intention is what really counts.
changelog:[`items_after_test_module`]: Ignore imported modules (`mod foo;`) with no body.
Using `default` to construct a unit struct increases code complexity and
adds a function call. This can be avoided by simply removing the call to
`default` and simply construct by name.
Add configuration for `semicolon_block` lints
Does exactly what it says on the tin, suggests moving a block's final semicolon inside if it's multiline and outside if it's singleline.
I don't really like how this is implemented so I'm not too sure if this is ready yet. Alas, it might be ok.
---
fixes#10654
changelog: Enhancement: [`semicolon_inside_block`]: Added `semicolon-inside-block-ignore-singleline` as a new config value.
[#10656](https://github.com/rust-lang/rust-clippy/pull/10656)
changelog: Enhancement: [`semicolon_outside_block`]: Added `semicolon-outside-block-ignore-multiline` as a new config value.
[#10656](https://github.com/rust-lang/rust-clippy/pull/10656)
<!-- changelog_checked -->
Improve the help message + add a help span
This would close#10410, because it applies the general consensus achieved in that issue (that replacing `let _ = ...` to `_ = ...` doesn't present any benefits).
I also added a little help message span.
changelog:[`let_underscore_untyped`]: Fix the help message confusion + add a help message span.
check for `..` pattern in `redundant_pattern_matching`
The `redundant_pattern_matching` lint currently checks for `if let Some(_) = ...`, but not for `if let Some(..) = ...`.
This PR makes sure to also check for the `..` pattern in tuple structs.
It also found one such instance in clippy itself so that shows it's worth checking for this pattern as well 😅
changelog: [`redundant_pattern_matching`]: check for `..` pattern in tuple structs
Fix false positive in `allow_attributes`
This would emit a warning if used in a proc-macro with the feature `lint_reasons` enabled. This is now fixed.
changelog: [`allow_attributes`]: Don't lint if in external macro
Ignore `shadow` warns in code from macro expansions
This PR fixes https://github.com/rust-lang/rust-clippy/issues/9757
I am in doubt if just looking for `pat.span.from_expansion()` would be sufficient instead of looking for both `pat.span.desugaring_kind().is_some()` or `pat.span.from_expansion()`. The tests (including the new one) passes if I leave the only `if pat.span.from_expansion()`. Any feedbacks?
Also, this is my first PR here, sorry for anything and thanks for the patience!
changelog: [`shadow_same`, `shadow_reuse`, `shadow_unrelated`]: avoiding warns in macro-generated code
New lint: detect `if` expressions with simple boolean assignments to the same target
Closes#10430
changelog: [`needless_bool_assign`] new lint to detect simple boolean assignment to the same target in `if` branches
use `is_inside_const_context` for `in_constant` util fn
Fixes#10452.
This PR improves the `in_constant` util function to detect more cases of const contexts. Previously this function would not detect cases like expressions in array length position or expression in an inline const block `const { .. }`.
changelog: [`bool_to_int_with_if`]: recognize array length operand as being in a const context and don't suggest `usize::from` there
Don't suggest `suboptimal_flops` unavailable in nostd
Fixes#10634
changelog: Enhancement: [`suboptimal_flops`]: Do not suggest `{f32,f64}::abs()` or `{f32,f64}::mul_add()` in a `no_std`-environment.
Add `items_after_test_module` lint
Resolves task *3* of #10506, alongside *1* resolved at #10543 in an effort to help standarize a little bit more testing modules.
---
changelog:[`items_after_test_module`]: Added the lint.
make [`len_zero`] lint not spanning over parenthesis
sorry it should be a quick fix but I was caught up by other stuffs last couple weeks 🤦♂️
---
fixes: #10529
changelog: make [`len_zero`] lint not spanning over parenthesis
Suppress the triggering of some lints in derived structures
Fixes#10185Fixes#10417
For `integer_arithmetic`, `arithmetic_side_effects` and `shadow_reuse`.
* ~~Not sure how to test these use-cases so feel free to point any method or any related PR.~~
---
changelog: FP: [`integer_arithmetic`], [`arithmetic_side_effects`]: No longer lint inside proc macros
[#10203](https://github.com/rust-lang/rust-clippy/pull/10203)
<!-- changelog_checked -->
Add size-parameter to unecessary_box_returns
Fixes#10641
This adds a configuration-knob to the `unecessary_box_returns`-lint which allows _not_ linting a `fn() -> Box<T>` if `T` is "large". The default byte size above which we no longer lint is 128 bytes (due to https://github.com/rust-lang/rust-clippy/issues/4652#issue-505670554, also used in #9373). The overall rational is given in #10641.
---
changelog: Enhancement: [`unnecessary_box_returns`]: Added new lint configuration `unnecessary-box-size` to set the maximum size of `T` in `Box<T>` to be linted
[#10651](https://github.com/rust-lang/rust-clippy/pull/10651)
<!-- changelog_checked -->
resolve: Pre-compute non-reexport module children
Instead of repeating the same logic by walking HIR during metadata encoding.
The only difference is that we are no longer encoding `macro_rules` items, but we never currently need them as a part of this list. They can be encoded separately if this need ever arises.
`module_reexports` is also un-querified, because I don't see any reasons to make it a query, only overhead.
Instead of repeating the same logic by walking HIR during metadata encoding.
The only difference is that we are no longer encoding `macro_rules` items, but we never currently need them as a part of this list.
They can be encoded separately if this need ever arises.
`module_reexports` is also un-querified, because I don't see any reasons to make it a query, only overhead.
Clear with drain
Fixes#10572: both the original intent of the issue (extending `clear_with_drain`) and the false negative for `collection_is_never_read` I found in the process are fixed by this PR.
changelog: [`clear_with_drain`]: extend to 5 other types of containers. [`collection_is_never_read`]: fix false negative for `String`s.
fix `single_component_path_imports` FP on `self::<import>::..`
fixes#10549
I noticed that a couple functions in the file I was working on took `cx` as a parameter but didn't use them, so I removed that. Can revert if desired because it isn't related to my changes.
changelog: [`single_component_path_imports`] don't suggest removing import when it is used as `self::<import>::..`
fix [`mem_replace_option_with_none`] not considering field variables
fixes: #9824
---
changelog: fix [`mem_replace_option_with_none`] not considering field variables
Make redundant_async_block a more complete late pass
This lets us detect more complex situations: `async { x.await }` is simplified into `x` if:
- `x` is an expression without side-effect
- or `x` is an `async` block itself
In both cases, no part of the `async` expression can be part of a macro expansion.
Fixes#10509.
Fixes#10525.
changelog: [`redundant_async_block`] Do not lint expressions with side effects.
This lets us detect more complex situations: `async { x.await }` is
simplified into `x` if:
- `x` is an expression without side-effect
- or `x` is an async block itself
In both cases, no part of the `async` expression can be part of a macro
expansion.
Add `tests_outside_test_module` lint
Adds `tests_outside_test_module` from #10506. This PR **doesn't** close the issue, just resolves task 1.
changelog: [`tests_outside_test_module`]: The lint has been added
Mini-fix `double_must_use` for async functions
From Rust 1.67 onwards, the `#[must_use]` attribute also applies to the `Future::Output` (rust-lang/rust#100633). So the lint `double_must_use` was linting all async functions. This PR changes the `double_must_use` lint so it ignores `async` functions.
---
Closes#10486
changelog: [`double_must_use`]: Fix false positive in async function
Partial no-op refactoring of #9948
This contains some prep work for #9948 to keep that change to the minimum, and make it easier to review it.
This should be a noop, but it has some tests from that PR discussion, and should help in the future with the corner case format handling.
cc: `@Alexendoo` `@llogiq` `@xFrednet` as the 3 people who reviewed the parent PR
----
changelog: none
Add suggestions to `extra_unused_type_parameters`
Change the `extra_unused_type_parameters` lint to provide machine applicable suggestions rather than just help messages. Exception to this are cases when any unused type parameters appear bounded in where clauses - for now I've deemed these cases unfixable and separated them out. Future work might be able to provide suggestions in these cases.
Also, added a test case for the `avoid_breaking_exported_api` config option.
r? `@flip1995`
changelog: [`extra_unused_type_parameters`]: Now provides fixable suggestions.
Added the `[unnecessary_box_returns]` lint
fixes#5
I'm not confident in the name of this lint. Let me know if you can think of something better
---
changelog: New lint: ``[`unnecessary_box_returns`]``
[#9102](https://github.com/rust-lang/rust-clippy/pull/9102)
<!-- changelog_checked -->
In uninit checking, add fallback for polymorphic types
After #10520, we always assumed that polymorphic types do not allow to be left uninitialized. But we can do better, by peeking into polymorphic types and adding a few special cases for going through tuples, arrays (because the length may be polymorphic) and blanket allowing all unions (like MaybeUninit).
fixes#10551
changelog: [uninit_vec]: fix false positive for polymorphic types
changelog: [uninit_assumed_init]: fix false positive for polymorphic types
Fix allow attribute, items from macros in `items_after_statements`
Fixes#10540
changelog: [`items_after_statements`]: Fixes `#[allow(clippy::items_after_statements)]` when applied to an item, and ignores items after statements from different macro contexts
fix [`cast_possible_truncation`] offering wrong suggestion for casting float to integer
fixes: #10366
---
changelog: [`cast_possible_truncation`] Fix incorrect suggestions when casting from float types or to `_`
Wrap `transmutes_expressible_as_ptr_casts` suggestions in parentheses
changelog: [`transmutes_expressible_as_ptr_casts`]: Fix suggestion missing wrapping parentheses
Fixes#10449
r? `@Jarcho`
Is this the best way to go about this? `unused_parens` will catch the unnecessary ones but emitting them in the first place isn't ideal
suggest `try_into` when casting to wildcard type;
fix [`cast_possible_truncation`] suggesting useless parenthesis;
remove suggesting for float to float conversion in [`cast_possible_truncation`]
style nit
New lint: detect unnecessary struct building
Fixes#10476.
Running this lint on the top 500 crates produced one hit (in `rust-lang/rust-bindgen`) and [a PR has been submitted there](https://github.com/rust-lang/rust-bindgen/pull/2440).
changelog: [`unnecessary_struct_initialization`]: new lint
Do not propose to simplify a not expression coming from a macro
Fixes#10523
changelog: FP [`nonminimal_bool`]: do not propose to change code coming from a macro
Do not propose to remove `async move` if variables are captured by ref
Fixes#10482
changelog: FP [`redundant_async_block`] Do not propose to remove `async move` if variables are captured by ref
Really dogfood clippy
The dogfood success condition was inverted in `tests/dogfood.rs`:
```rust
assert!(!failed_packages.is_empty(), …);
```
while instead the `failed_packages` collection must be empty:
```rust
assert!(failed_packages.is_empty(), …);
```
And indeed, several clippy lint source files were not clean and had to be fixed in the process.
changelog: none
The dogfood success condition was inverted in `tests/dogfood.rs`:
```rust
assert!(!failed_packages.is_empty(), …);
```
while instead the `failed_packages` collection must be empty:
```rust
assert!(failed_packages.is_empty(), …);
```
And indeed, several clippy lint source files were not clean and had to be
fixed in the process.
rustc has proper heuristics for actually checking whether a type allows
being left uninitialized (by asking CTFE). We can now use this for our
helper instead of rolling our own bad version with false positives.
Issue function modifiers in the right order in manual_async_fn lint
Fixes#10450
changelog: [`manual_async_fn`] output function modifiers in correct order
fix `almost_swapped`: Ignore external macros
Fixes#10421 ; Related to #10499 (Fixing points *1* and *3* from #10421)
changelog: [`almost_swapped`]: Add a check to ignore external macros
Fix `almost_swapped` false positive (`let mut a = b; a = a`)
Fixes `2` in #10421
changelog: [`almost_swapped`]: Fix false positive when a variable is changed to itself. (`a = a`)
Remove `identity_future` indirection
This was previously needed because the indirection used to hide some unexplained lifetime errors, which it turned out were related to the `min_choice` algorithm.
Removing the indirection also solves a couple of cycle errors, large moves and makes async blocks support the `#[track_caller]`annotation.
Fixes https://github.com/rust-lang/rust/issues/104826.
enhance [`ifs_same_cond`] to warn same immutable method calls as well
fixes: #10272
---
changelog: Enhancement: [`ifs_same_cond`]: Now also detects immutable method calls.
[#10350](https://github.com/rust-lang/rust-clippy/pull/10350)
<!-- changelog_checked -->
Remove `box_syntax`
r? `@Nilstrieb`
This removes the feature `box_syntax`, which allows the use of `box <expr>` to create a Box, and finalises removing use of the feature from the compiler. `box_patterns` (allowing the use of `box <pat>` in a pattern) is unaffected.
It also removes `ast::ExprKind::Box` - the only way to create a 'box' expression now is with the rustc-internal `#[rustc_box]` attribute.
As a temporary measure to help users move away, `box <expr>` now parses the inner expression, and emits a `MachineApplicable` lint to replace it with `Box::new`
Closes#49733
Strengthen state tracking in const-prop
Some/many of the changes are replicated between both the const-prop lint and the const-prop optimization.
Behaviour changes:
- const-prop opt does not give a span to propagated values. This was useless as that span's primary purpose is to diagnose evaluation failure in codegen.
- we remove the `OnlyPropagateInto` mode. It was only used for function arguments, which are better modeled by a write before entry.
- the tracking of assignments and discriminants make clearer that we do nothing in `NoPropagation` mode or on indirect places.
Add utility macros to help with writing tests.
Adds two utility macros to help with testing:
* `external` expands to it's argument tokens, but makes them appear to come from an external macro. Helps make tests for `in_external_macro` much more readable.
* `inline_macros` is an attribute macro which allows the use of a pseudo `inline!` macro which expands to it's argument tokens, but makes them appear to be from a crate-local macro expansion. This removes the need to write `macro_rules` boilerplate when testing how lints interact with macros.
---
`external`'s usage is simple. `external!(struct Foo { x: u32});` will make the struct appear as though it came from an external macro. Individual tokens can be escaped if needed. `external!($x + 0 / 10)` will make everything except `x` appear as though it came from an external macro. Can also use `$literal` and `$(tokens...)` as well.
---
`inline_macros` is more complicated due to compiler constraints. Given:
```rust
#[inline_macros]
fn foo() {
inline!(5 + 5 / 10);
}
```
`inline!(5 + 5 / 10)` will be replace with a call to a generated macro which expands to the contained tokens.
Tokens can be escaped by prefixing them with `$`:
```rust
#[inline_macros]
fn foo() {
let x = 5;
inline!($x + 5 / $10);
}
```
This will pass `x` as an `ident` argument and `10` as a `literal` argument.
Token sequences can also be passed with `$(...)`:
```rust
#[inline_macros]
fn foo() {
let mut x = 5;
inline!(if $(x >= 5) {
$x = 5;
});
}
```
This will pass `x >= 5` as `tt` arguments, and `x` as an `ident` argument.
---
Not 100% sure `inline_macros` is actually worth having. It does make the tests a little easier to read once you're used to it and it becomes more useful once there are multiple macro tests. The verbosity of declaring single use macros starts to hurt at that point.
changelog: None
Improve diagnostic of `no_mangle_with_rust_abi`
fixes#10409
Pending rust-lang/rustfmt#5701
This rewords the message to focus on the error being an implicit ABI, rather than the `Rust` ABI. Also downgrades the suggestion to `MaybeIncorrect` and changes the suggestion span to better highlight the change.
---
changelog: None
<!-- changelog_checked -->
Migrate `write.rs` to `rustc_ast::FormatArgs`
changelog: none
Part 1 of #10233
The additions to `clippy_utils` are the main novelty of this PR, there's no removals yet since other parts still rely on `FormatArgsExpn`
The changes to `write.rs` itself are relatively straightforward this time around, as there's no lints in it that rely on type checking format params
r? `@flip1995`
Include async functions in the len_without_is_empty
fixes#7232
Changes done to the functionality:
Allowing different error types for the functions was disallowed. So the following was linted before but is not after this change
```
impl Foo {
pub len(&self) -> Result<usize, Error1> { todo!(); }
pub is_empty(&self) -> Result<bool, Error2> { todo!(); }
}
```
---
changelog: Enhancement: [`len_without_is_empty`]: Now also detects `async` functions
[#10359](https://github.com/rust-lang/rust-clippy/pull/10359)
<!-- changelog_checked -->
[arithmetic_side_effects] Fix#10252Fix#10252
At least for integers, shifts are already handled by the compiler.
----
changelog: [`arithmetic_side_effects`]: No longer lints on right or left shifts with constant integers, as the compiler warns about them.
[#10309](https://github.com/rust-lang/rust-clippy/pull/10309)
<!-- changelog_checked-->
This was previously needed because the indirection used to hide some unexplained lifetime errors, which it turned out were related to the `min_choice` algorithm.
Removing the indirection also solves a couple of cycle errors, large moves and makes async blocks support the `#[track_caller]` annotation.
Add `collection_is_never_read`
Fixes#9267
`@flip1995` and `@llogiq,` I talked with you about this one at Rust Nation in London last week. :-)
This is my first contribution to Clippy, so lots of feedback would be greatly appreciated.
- \[ ] Followed [lint naming conventions][lint_naming]
- \[x] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[x] Executed `cargo dev update_lints`
- \[x] Added lint documentation
- \[x] Run `cargo dev fmt`
`dogfood` found one true positive (see #9509) and no false positives.
`lintcheck` found no (true or false) positives, even when running on an extended set of crates.
---
changelog: new lint [`collection_is_never_read`]
[#10415](https://github.com/rust-lang/rust-clippy/pull/10415)
<!-- changelog_checked -->
Scope `missing_docs_in_private_items` to only private items
`missing_docs_in_private_items` currently detects missing docs for public items as well as private. Since `missing_docs`already covers public items, this PR updates `missing_docs_in_private_items` to only cover private items.
Fixes#1895
changelog: [`missing_docs_in_private_items`]: Apply lint only to private items (used to be public and private)
Run dogfood to completion
Run dogfood on all packages before failing the test. Failing early is painful on lints which trigger on multiple crates.
changelog: None
Fix ICE in `multiple_unsafe_ops_per_block`
fixes#10367
changelog: [`multiple_unsafe_ops_per_block`]: Fix ICE when calling a function-like object in an unsafe block
Do not suggest to derive `Default` on generics with implicit arguments
Fixes#10396
changelog: FP: [`derivable_impls`]: do not suggest to derive `Default` on generics with implicit arguments
chore: remove unneeded rustfmt skip
---
The associated rustfmt bug that originally necessitated these skips was resolved a while back, so these are no longer necessary
changelog: none
Fix test function checker in `unwrap_used`, `expect_used`
After #9686 , `unwrap` and `expect` in integration tests and raw test functions won't be allowed.
fixes#10011fixes#10238fixes#10264
---
changelog: Fix: [`expect_used`], [`unwrap_used`], [`dbg_macro`], [`print_stdout`], [`print_stderr`]: No longer lint in test functions, if the related configuration is set
[#10391](https://github.com/rust-lang/rust-clippy/pull/10391)
<!-- changelog_checked -->
Normalize projections types when checking `explicit_auto_deref`
fixes#10384
changelog: [`explicit_auto_deref`]: Better consider projection types when checking if auto deref is applicable
Ignore lifetimes from differing contexts in `needless_lifetimes`
Fixes#10379
changelog: [`needless_lifetimes`]: Don't lint signatures in macros if the lifetime is a metavariable
Add `impl_trait_in_params` lint
As this is a lint about style, and using `impl Trait` is purely cosmetical (even with downsides), a lot of unrelated files needed to allow this lint.
---
Resolves#10030
changelog: New lint: [`impl_trait_in_params`]
[10197](https://github.com/rust-lang/rust-clippy/pull/10197)
<!-- changelog_checked -->
Add configuration to lint missing docs of `pub(crate)` items
Fixes this: https://github.com/rust-lang/rust-clippy/issues/5736#issuecomment-1412442404
TODO:
- [x] Needs docs
- [x] Needs better names
- [x] Should `pub` items be checked to when this new option is enabled? I'm saying no because `missing_docs` already exists
`@flip1995` I'd like to get some input from you :)
---
changelog: Enhancement: [`missing_docs_in_private_items`]: Added new configuration `missing-docs-in-crate-items` to lint on items visible within the current crate. For example, `pub(crate)` items.
[#10303](https://github.com/rust-lang/rust-clippy/pull/10303)
<!-- changelog_checked -->
Within a larger expression, when the type of `Box::new(T::default())` is
`Box<dyn Trait>`, the concrete type `T` cannot be omitted in the
proposed replacement `Box::<T>::default()`.
[significant_drop_tightening] Ignore inexpensive statements
Not all statements that follow the last use of a lock guard are expensive and can therefore be ignored by the lint.
```rust
pub fn foo() -> i32 {
let mutex = Mutex::new(1);
let lock = mutex.lock().unwrap();
let rslt = *lock;
let another = rslt;
another
}
```
---
changelog: [`significant_drop_tightening`]: No longer lints for inexpensive statements after the lock guard
[#10363](https://github.com/rust-lang/rust-clippy/pull/10363)
<!-- changelog_checked -->
manual_let_else: do not suggest semantically different replacements
The problem is that this lint does not consider the possibility that the divergent branch can come first and that the patterns may overlap. This led to incorrect suggestions, previously registered as correct in the tests themselves:
```rust
let v = match build_enum() {
_ => continue,
Variant::Bar(v) | Variant::Baz(v) => v,
};
```
had a `let Variant::Bar(v) | Variant::Baz(v) = v else { continue; }` suggestion, which is obviously wrong as the original code `continue`s in any case. Issue #10241 gives another example.
The code now checks that the divergent branch comes second. It could be extended later (I've added a TODO) to check for non-overlapping patterns.
Fixes#10241.
changelog: [`manual_let_else`] do not suggest non equivalent replacements in `match`
Stop bytes_nth from suggesting code that does not compile
Fixes#10151
As discussed in the issue, this PR changes the lint in 2 ways
1. Replace `bytes().nth(n).unwrap()` with `as_bytes()[n]`
2. Replace other `bytes().nth(n)` with `as_bytes().get(n).copied()`
---
changelog: Stop bytes_nth from suggesting code that does not compile in some cases
Stop doc_markdown requiring backticks on links to external websites
Fixes#10302
This lint currently checks that any link should be enclosed with `backticks` if the title looks like a lang item. This PR changes the lint to only run on internal links. External links, indicated by `http` or `https`, are skipped.
This PR also reorganises `pulldown_cmark` imports to bypass the clippy lint enforcing 100 line functions.
---
changelog: Stop doc_markdown requiring backticks on links to external websites
Add question-mark-used lint
This lint complains when the question mark operator (try operator) is used. This is a restriction lint that can be useful on local scopes where a custom error handling macro is supposed to be used to augment the error based on local scope data before returning.
Fixes#10340
---
changelog: New lint [`question_mark_used`]
[#10342](https://github.com/rust-lang/rust-clippy/pull/10342)
<!-- changelog_checked -->
Add `let_underscore_untyped`
Fixes#6842
This adds a new pedantic `let_underscore_untyped` lint which checks for `let _ = <expr>`, and suggests to either provide a type annotation, or to remove the `let` keyword. That way the author is forced to specify the type they intended to ignore, and thus get forced to re-visit the decision should the type of `<expr>` change. Alternatively, they can drop the `let` keyword to truly just ignore the value no matter what.
r? `@llogiq`
changelog: New lint: [let_underscore_untyped]
[significant_drop_tightening] Add MVP
cc #9399
Creates the lint with minimum functionalities, which is a good start IMO.
---
changelog: new lint: [`significant_drop_tightening`]
[#10163](https://github.com/rust-lang/rust-clippy/pull/10163)
<!-- changelog_checked -->
As this is a lint about "style", and a purely cosmetical choice (using `<A: Trait>` over `impl Trait`), a lot of other files needed to be allowed this lint.
Fix false positives for `extra_unused_type_parameters`
Don't lint external macros. Also, if the function body is empty, any type parameters with bounds on them are not linted. Note that only the body needs be empty - this rule still applies if the function takes any arguments.
fixes#10318fixes#10319
changelog: none
<!-- changelog_checked -->
uninlined_format_args: do not inline argument with generic parameters
Fix#10339
---
changelog: FP: [`uninlined_format_args`]: No longer lints for arguments with generic parameters
[#10343](https://github.com/rust-lang/rust-clippy/pull/10343)
<!-- changelog_checked -->
fix [`needless_return`] incorrect suggestion when returning if sequence
fixes: #10049
---
changelog: [`needless_return`]: fix incorrect suggestion on if sequence
Liberate late-bound regions rather than erasing them in `needless_pass_by_value`
changelog: [`needless_pass_by_value`]: fixes an ICE when there are late-bound regions in function arguments that are needlessly passed by value
Fixesrust-lang/rust#107147
r? `@matthiaskrgr`
It is not sufficient to ignore break from a block inside the loop.
Instructions after the break must be ignored, as they are unreachable.
This is also true for all instructions in outer blocks and loops
until the right block is reached.
This lint complains when the question mark operator (try operator)
is used. This is a restriction lint that can be useful on local
scopes where a custom error handling macro is supposed to be used
to augment the error based on local scope data before returning.
Negate suggestions when needed in `bool_assert_comparison`
changelog: none assuming this gets into the same release as #10218Fixes#10291
r? `@dswij`
Thanks to `@black-puppydog` for spotting it early
wildcard_enum_match_arm lint takes the enum origin into account
fixes#7419
---
changelog: Enhancement: [`wildcard_enum_match_arm`]: Now lints missing private variants, for local enums
[#10250](https://github.com/rust-lang/rust-clippy/pull/10250)
<!-- changelog_checked -->
[`unused_io_amount`]: Lint with `is_ok` and `is_err`
Fixes#10132
changelog: Apply [`unused_io_amount`] lint to `is_ok` and `is_err` without checking read/write amount
prevents `len_without_is_empty` from yielding positive when `len` takes arguments besides `&self`
Fixes#9520
---
changelog: FP [`len_without_is_empty`]: No longer lints, if `len` as a non-default signature
[#10255](https://github.com/rust-lang/rust-clippy/pull/10255)
<!-- changelog_checked -->
more than just `&self` in non-standard implementations.
changelog: Fix [`len_without_is_empty`] false positive when len has a
non-standard method signature
Fixes#9520
`invalid_regex`: Show full error when string value doesn't match source
changelog: [`invalid_regex`]: Show full error when parsing non-literals or regular strings containing escape sequences
Fixes#4170, the escape sequence there causes the span to be incorrect which will have caused most of the confusion
Add `multiple_unsafe_ops_per_block` lint
Adds a lint, which restricts an `unsafe` block to only one unsafe operation.
Closes#10064
---
changelog: New lint: [`multiple_unsafe_ops_per_block`]
[#10206](https://github.com/rust-lang/rust-clippy/pull/10206)
<!-- changelog_checked -->
Fix suggestion in `transmutes_expressible_as_ptr_casts` when the source type is a borrow.
fixes#9894
changelog: `transmutes_expressible_as_ptr_casts`: Fix suggestion when the source type is a borrow.
[needless_return]: Remove all semicolons on suggestion
Closes#10182
Multiple semicolons currently breaks autofix for `needless_return` suggestions. Any semicolons left after removing return means that the return type will always be `()`, and thus fail to compile.
This PR allows `needless_return` to remove multiple semicolons.
The change won't cover the case where there is multiple line yet.
i.e.
```rust
fn needless_return() -> bool {
return true;
;;
}
```
---
changelog: Sugg: [`needless_return`]: Now removes all semicolons on the same line
[#10187](https://github.com/rust-lang/rust-clippy/pull/10187)
<!-- changelog_checked -->
`cast_possible_truncation` Suggest TryFrom when truncation possible
This fixes the last issues from https://github.com/rust-lang/rust-clippy/pull/9664 as the author seems to be inactive. The PR author was sadly kept during the rebase, due to the conflict resolution.
IDK if it's worth it do to a full review, I only added the last commit, everything else remained the same, besides a rebase.
---
changelog: Sugg: [`cast_possible_truncation`]: Now suggests using `try_from` or allowing the lint
[#10038](https://github.com/rust-lang/rust-clippy/pull/10038)
<!-- changelog_checked -->
closes: https://github.com/rust-lang/rust-clippy/issues/9231
Render missing generics suggestion verbosely
It's a bit easier to read like this, especially ones that are appending new generics onto an existing list, like ": `, T`" which render somewhat poorly inline.
Also don't suggest `dyn` as a type parameter to add, even if technically that's valid in edition 2015.
Whne SYSROOT is defined, clippy-driver will insert a --sysroot argument
when calling rustc. However, when a sysroot argument is already defined,
e.g. through RUSTFLAGS=--sysroot=... the `cargo clippy` call would
error. This tests that the sysroot argument is only passed once and that
SYSROOT is ignored in this case.
This is useful for rust-lang/rust to allow setting a sysroot that's
*only* for build scripts, different from the regular sysroot passed in
RUSTFLAGS (since cargo doesn't apply RUSTFLAGS to build scripts or
proc-macros).
That said, the exact motivation is not particularly important: this
fixes a regression from
5907e9155e (r1060215684).
Note that only RUSTFLAGS is tested in the new integration test; passing
--sysroot through `clippy-driver` never worked as far as I can tell, and
no one is using it, so I didn't fix it here.
Allow implementing `Hash` with derived `PartialEq` (`derive_hash_xor_eq`
This is a common pattern and is totally allowed by the `Hash` trait.
Fixes#2627
changelog: Move: Renamed `derive_hash_xor_eq` to [`derived_hash_with_manual_eq`]
[#10184](https://github.com/rust-lang/rust-clippy/pull/10184)
changelog: Enhancement: [`derived_hash_with_manual_eq`]: Now allows `#[derive(PartialEq)]` with custom `Hash` implementations
[#10184](https://github.com/rust-lang/rust-clippy/pull/10184)
<!-- changelog_checked -->
trim paths in `suspicious_to_owned`
This continues my path trimming spree. I'm not going to add yet another changelog entry, we should have one "trim paths in some applicable lints" entry instead.
---
changelog: none
unused_self: Don't trigger if the method body contains todo!()
If the author is using todo!(), presumably they intend to use self at some point later, so we don't have a good basis to recommend factoring out to an associated function.
Fixes#10117.
---
changelog: Enhancement: [`unused_self`]: No longer lints, if the method body contains a `todo!()` call
[#10166](https://github.com/rust-lang/rust-clippy/pull/10166)
<!-- changelog_checked -->
[arithmetic_side_effects] Add more tests related to custom types
Add tests to ensure that custom types are triggered with any type of arithmetic operation as well as combinations with or without references.
---
changelog: none
<!-- changelog_checked -->
trim paths in `box_default`
This might help with #10089, though I have not tested that yet. In any event, it keeps the suggestion short and to the point.
---
changelog: Trim paths in [`box_default`] suggestion
trim paths in `default_trait_access`/`clone_on_copy` suggestions
This should help making the suggestions more palatable. Similar to #10153.
---
changelog: trim paths in [`default_trait_access`]/[`clone_on_copy`] suggestions
If the author is using todo!(), presumably they intend to use self at
some point later, so we don't have a good basis to recommend factoring
out to an associated function.
Fixes#10117.
changelog: Don't trigger [`unused_self`] if the method body contains a `todo!()` call
[`drop_ref`]: don't lint idiomatic in match arm
fixes#10122
As established in issue #9482, it is idiomatic to use a single `drop()` expression in a match arm to achieve a side-effect of a function while discarding its output. This should also apply to cases where the function returns a reference.
The change to the lint's code was less than 1 line, because all the heavy lifting was done in PR #9491.
---
changelog: FP: [`drop_ref`]: No longer lints idiomatic expression in `match` arms
[#10142](https://github.com/rust-lang/rust-clippy/pull/10142)
<!-- changelog_checked -->
Make the iter_kv_map lint handle ref/mut annotations.
For the degenerate (`map(|(k, _)| k)`/`map(|(_, v)| v)`) cases a mut annotation is superfluous and a ref annotation won't compile, so no additional handling is required. For cases where the `map` call must be preserved ref/mut annotations should also be presereved so that the map body continues to work as expected.
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: [`iter_kv_map`]: handle ref/mut annotations
For the degenerate (`map(|(k, _)| k)`/`map(|(_, v)| v)`) cases a mut annotation is superfluous and a ref annotation won't compile, so no additional handling is required. For cases where the `map` call must be preserved ref/mut annotations should also be presereved so that the map body continues to work as expected.
don't lint field_reassign when field in closure
fixes#10136
This change makes the ContainsName struct visit all interior expressions, which means that ContainsName will return true even if `name` is used in a closure within `expr`.
---
changelog: FP: [`field_reassign_with_default`]: No longer lints cases, where values are initializes from closures capturing struct values
[#10143](https://github.com/rust-lang/rust-clippy/pull/10143)
<!-- changelog_checked -->
This commit makes the ContainsName struct visit all interior
expressions, which means that ContainsName will return true
even if `name` is used in a closure within `expr`.
fix incorrect suggestion in `suboptimal_flops`
fixes#10003
There was an error when trying to negate an expression like `x - 1.0`. We used to format it as `-x - 1.0` whereas a proper negation would be `-(x - 1.0)`.
Therefore, we add parentheses around the expression when it is `ExprKind::Binary`.
We also add parentheses around multiply and divide expressions, even though this is not strictly necessary.
changelog: [`suboptimal_flops`]: fix incorrect suggestion caused by an incorrect negation of floating point expressions.
There was an error when trying to negate an expression
like `x - 1.0`. We used to format it as `-x - 1.0` whereas
a proper negation would be `-(x - 1.0)`.
Therefore, we add parentheses around the expression when it is a
Binary ExprKind.
We also add parentheses around multiply and divide expressions,
even though this is not strictly necessary.
Add size_of_ref lint
This addresses #9995, which is likely raising a valid point about `std::mem::size_of_val()`: It's [very easy to use double-references as the argument](https://github.com/apache/arrow-datafusion/pull/4371#discussion_r1032385224), which the function will happily accept and give back the size of _the reference_, not the size of the value _behind_ the reference. In the worst case, if the value matches the programmer's expectation, this seems to work, while in fact, everything will go horribly wrong e.g. on a different platform.
The size of a `&T` is independent of what `T` is, and people might want to use `std::mem::size_of_val()` to actually get the size of _any_ reference (e.g. via `&&()`). I would rather suggest that this is always bad behavior, though ([instead](https://doc.rust-lang.org/reference/type-layout.html#pointers-and-references-layout), [and](https://doc.rust-lang.org/stable/std/primitive.usize.html#associatedconstant.BITS)). I, therefore, put this lint into `correctness`.
Since the problem is usually easily fixed by removing extra `&`, I went light on suggesting code.
---
changelog: New lint: [`size_of_ref`]
[#10098](https://github.com/rust-lang/rust-clippy/pull/10098)
<!-- changelog_checked -->
Improve `possible_borrower`
This PR makes several improvements to `clippy_uitls::mir::possible_borrower`. These changes benefit both `needless_borrow` and `redundant clone`.
1. **Use the compiler's `MaybeStorageLive` analysis**
I could spot not functional differences between the one in the compiler and the one in Clippy's repository. So, I removed the latter in favor of the the former.
2. **Make `PossibleBorrower` a dataflow analysis instead of a visitor**
The main benefit of this change is that allows `possible_borrower` to take advantage of statements' relative locations, which is easier to do in an analysis than in a visitor.
This is easier to illustrate with an example, so consider this one:
```rust
fn foo(cx: &LateContext<'_>, lint: &'static Lint) {
cx.struct_span_lint(lint, rustc_span::Span::default(), "", |diag| diag.note(&String::new()));
// ^
}
```
We would like to flag the `&` pointed to by the `^` for removal. `foo`'s MIR begins like this:
```rust
fn span_lint::foo::{closure#0}(_1: [closure@$DIR/needless_borrow.rs:396:68: 396:74], _2: &mut rustc_errors::diagnostic_builder::DiagnosticBuilder<'_, ()>) -> &mut rustc_errors::diagnostic_builder::DiagnosticBuilder<'_, ()> {
debug diag => _2; // in scope 0 at $DIR/needless_borrow.rs:396:69: 396:73
let mut _0: &mut rustc_errors::diagnostic_builder::DiagnosticBuilder<'_, ()>; // return place in scope 0 at $DIR/needless_borrow.rs:396:75: 396:75
let mut _3: &mut rustc_errors::diagnostic_builder::DiagnosticBuilder<'_, ()>; // in scope 0 at $DIR/needless_borrow.rs:396:75: 396:100
let mut _4: &mut rustc_errors::diagnostic_builder::DiagnosticBuilder<'_, ()>; // in scope 0 at $DIR/needless_borrow.rs:396:75: 396:100
let mut _5: &std::string::String; // in scope 0 at $DIR/needless_borrow.rs:396:85: 396:99
let _6: std::string::String; // in scope 0 at $DIR/needless_borrow.rs:396:86: 396:99
bb0: {
StorageLive(_3); // scope 0 at $DIR/needless_borrow.rs:396:75: 396:100
StorageLive(_4); // scope 0 at $DIR/needless_borrow.rs:396:75: 396:100
_4 = &mut (*_2); // scope 0 at $DIR/needless_borrow.rs:396:75: 396:100
StorageLive(_5); // scope 0 at $DIR/needless_borrow.rs:396:85: 396:99
StorageLive(_6); // scope 0 at $DIR/needless_borrow.rs:396:86: 396:99
_6 = std::string::String::new() -> bb1; // scope 0 at $DIR/needless_borrow.rs:396:86: 396:99
// mir::Constant
// + span: $DIR/needless_borrow.rs:396:86: 396:97
// + literal: Const { ty: fn() -> std::string::String {std::string::String::new}, val: Value(<ZST>) }
}
bb1: {
_5 = &_6; // scope 0 at $DIR/needless_borrow.rs:396:85: 396:99
_3 = rustc_errors::diagnostic_builder::DiagnosticBuilder::<'_, ()>::note::<&std::string::String>(move _4, move _5) -> [return: bb2, unwind: bb4]; // scope 0 at $DIR/needless_borrow.rs:396:75: 396:100
// mir::Constant
// + span: $DIR/needless_borrow.rs:396:80: 396:84
// + literal: Const { ty: for<'a> fn(&'a mut rustc_errors::diagnostic_builder::DiagnosticBuilder<'_, ()>, &std::string::String) -> &'a mut rustc_errors::diagnostic_builder::DiagnosticBuilder<'_, ()> {rustc_errors::diagnostic_builder::DiagnosticBuilder::<'_, ()>::note::<&std::string::String>}, val: Value(<ZST>) }
}
```
The call to `diag.note` appears in `bb1` on the line beginning with `_3 =`. The `String` is owned by `_6`. So, in the call to `diag.note`, we would like to know whether there are any references to `_6` besides `_5`.
The old, visitor approach did not consider the relative locations of statements. So all borrows were treated the same, *even if they occurred after the location of interest*.
For example, before the `_3 = ...` call, the possible borrowers of `_6` would be just `_5`. But after the call, the possible borrowers would include `_2`, `_3`, and `_4`.
So, in a sense, the call from which we are try to remove the needless borrow is trying to prevent us from removing the needless borrow(!).
With an analysis, things do not get so muddled. We can determine the set of possible borrowers at any specific location, e.g., using a `ResultsCursor`.
3. **Change `only_borrowers` to `at_most_borrowers`**
`possible_borrowers` exposed a function `only_borrowers` that determined whether the borrowers of some local were *exactly* some set `S`. But, from what I can tell, this was overkill. For the lints that currently use `possible_borrower` (`needless_borrow` and `redundant_clone`), all we really want to know is whether there are borrowers *other than* those in `S`. (Put another way, we only care about the subset relation in one direction.) The new function `at_most_borrowers` takes this more tailored approach.
4. **Compute relations "on the fly" rather than using `transitive_relation`**
The visitor would compute and store the transitive closure of the possible borrower relation for an entire MIR body.
But with an analysis, there is effectively a different possible borrower relation at each location in the body. Computing and storing a transitive closure at each location would not be practical.
So the new approach is to compute the transitive closure on the fly, as needed. But the new approach might actually be more efficient, as I now explain.
In all current uses of `at_most_borrowers` (previously `only_borrowers`), the size of the set of borrowers `S` is at most 2. So you need only check at most three borrowers to determine whether the subset relation holds. That is, once you have found a third borrower, you can stop, since you know the relation cannot hold.
Note that `transitive_relation` is still used by `clippy_uitls::mir::possible_origin` (a kind of "subroutine" of `possible_borrower`).
cc: `@Jarcho`
---
changelog: [`needless_borrow`], [`redundant_clone`]: Now track references better and detect more cases
[#9701](https://github.com/rust-lang/rust-clippy/pull/9701)
<!-- changelog_checked -->
Avoid `match_wildcard_for_single_variants` on guarded wild matches
fix#9993
changelog: FP: [`match_wildcard_for_single_variants`]: No longer lints on wildcards with a guard
[#10056](https://github.com/rust-lang/rust-clippy/pull/10056)
<!-- changelog_checked -->
r? `@Jarcho`
Null fn lints
Adds lints to check for code, that assumes nullable `fn()`.
### Lint examples:
`transmute_null_to_fn`:
```rust
error: transmuting a known null pointer into a function pointer
--> $DIR/transmute_null_to_fn.rs:9:23
|
LL | let _: fn() = std::mem::transmute(std::ptr::null::<()>());
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this transmute results in undefined behavior
|
= help: try wrapping your function pointer type in `Option<T>` instead, and using `None` as a null pointer value
```
`fn_null_check`:
```rust
error: function pointer assumed to be nullable, even though it isn't
--> $DIR/fn_null_check.rs:13:8
|
LL | if (fn_ptr as *mut ()).is_null() {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: try wrapping your function pointer type in `Option<T>` instead, and using `is_none` to check for null pointer value
```
Closes#1644
---
changelog: Improvement: [`transmuting_null`]: Now detects `const` pointers to all types
[#10099](https://github.com/rust-lang/rust-clippy/pull/10099)
changelog: New lint: [`transmute_null_to_fn`]
[#10099](https://github.com/rust-lang/rust-clippy/pull/10099)
changelog: New lint: [`fn_null_check`]
[#10099](https://github.com/rust-lang/rust-clippy/pull/10099)
<!-- changelog_checked (This is just a flag for me, please don't add it manually) -->
Identify more cases of useless `into_iter()` calls
changelog: Sugg: [`useless_conversion`]: Now suggests removing calls to `into_iter()` on an expression implementing `Iterator`
[#10020](https://github.com/rust-lang/rust-clippy/pull/10020)
<!-- changelog_checked -->
If the type of the result of a call to `IntoIterator::into_iter()`
and the type of the receiver are the same, then the receiver
implements `Iterator` and `into_iter()` is the identity function.
The call to `into_iter()` may be removed in all but two cases:
- If the receiver implements `Copy`, `into_iter()` will produce
a copy of the receiver and cannot be removed. For example,
`x.into_iter().next()` will not advance `x` while `x.next()` will.
- If the receiver is an immutable local variable and the call to
`into_iter()` appears in a larger expression, removing the call to
`into_iter()` might cause mutability issues. For example, if `x`
is an immutable local variable, `x.into_iter().next()` will
compile while `x.next()` will not as `next()` receives
`&mut self`.
Rustup
r? `@ghost`
I'm on the train and my internet is too bad to download the necessary toolchain, so I have to use CI to find sync fallout.
changelog: none
<!-- changelog_checked -->
fix: not suggest seek_to_start_instead_of_rewind when expr is used
changelog: [`seek_to_start_instead_of_rewind`]: No longer lints, if the return of `seek` is used.
[#10096](https://github.com/rust-lang/rust-clippy/pull/10096)
<!-- changelog_checked -->
Fixes#10065
There used to be a logical bug where IncrementVisitor would
completely stop checking an expression/block after seeing a continue
statement. This led to issue #10058 where a variable incremented
(or otherwise modified) after any continue statement would still be
considered incremented only once.
The solution is to continue scanning the expression after seeing a
`continue` statement, but increment self.depth so that the Visitor
thinks that the rest of the loop is within a conditional.
Cleanup `rustc_tool_util` and add a convenient macro for `build.rs`
changelog: none
<!-- changelog_checked -->
If possible, I'd like to have a new release for this, maybe `v0.3.0` to use the changes in another project. Then we can also remove the `path = "./rustc_tools_util"` from `Cargo.toml`. I'd be happy to help with the release on crates.io if you'd like the help :)
r? `@matthiaskrgr`
improve `manual_is_ascii_check ` check
Sorry, not familiar the api, i can only check the method name of expression `<expr-1>.contains(<expr-2>)` after read clippy book and hints from #9933 . i dont know how to check
1. if <expr-1> is a specific range
2. <expr-2> is a character
r? `@xFrednet` could you please provide some more hints? 😝️
---
changelog: Enhancement: [`manual_is_ascii_check`]: Now detects ranges with `.contains()` calls
[#10053](https://github.com/rust-lang/rust-clippy/pull/10053)
<!-- changelog_checked -->
Add 1.58 MSRV for `collapsible_str_replace`
The `Pattern` impl for `[char; N]` was added in 1.58
changelog: Enhancement: [`collapsible_str_replace`]: Now takes MSRV into consideration. The minimal version is 1.58
[#10047](https://github.com/rust-lang/rust-clippy/pull/10047)
add `suppress_restriction_lint_in_const` config
According to #9808 , add a new lint `suppress_lint_in_const` to report even in const context. BTW, i am not good at naming either, if anyone have a better idea, i am happy to change it.
This PR is still in progress, so i keep it draft.
- \[x] Followed [lint naming conventions][lint_naming]
- \[x] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[x] Executed `cargo dev update_lints`
- \[x] Added lint documentation
- \[x] Run `cargo dev fmt`
changelog: Enhancement: [`indexing_slicing`]: add new config `suppress-restriction-lint-in-const` to enable restriction lints, even if the suggestion might not be applicable
r? `@xFrendet`
Fix 10021
This PR proposes a fix for #10021.
The problem is similar to the one that `@mikerite` described in #9505. The compiler is generating an empty substitution for a call, even though the type of `Self` seems to be needed for a predicate. In `@mikerite's` case, the call was to [`IntoFuture::into_future`](https://doc.rust-lang.org/std/future/trait.IntoFuture.html#tymethod.into_future). In this case, the call is to [`Try::branch`](https://doc.rust-lang.org/std/ops/trait.Try.html#tymethod.branch).
The proposed fix is to verify that the parameter whose type is changing has an index within the substitution. The strikes me as a reasonable approach, since if the check were to fail, the following code would be a no-op:
4c123a06ba/clippy_lints/src/methods/unnecessary_to_owned.rs (L420-L428)
Like `@mikerite's` original solution, this solution turns ICEs into false negatives.
changelog: fix `unnecessary_to_owned` false positive involving `Try::branch`
Don't lint `implicit_clone` when the type doesn't implement clone
fixes#10019
changelog: `implicit_clone`: Don't lint when the type doesn't implement clone
Fix#9958
This PR fixes#9958. In order to fix the issue, the lint will now peel reference operators and enclose the expression with parentheses when necessary.
changelog: [`comparison_to_empty`]: Peel deref operators in suggestions when necessary
Don't lint `from_over_into` for opaque types
fixes#9935
This is stalled until the next sync. The impl in question can't be written on the pinned nightly.
changelog: Don't lint `from_over_into` for opaque types
rustc_ast_lowering: Stop lowering imports into multiple items
Lower them into a single item with multiple resolutions instead.
This also allows to remove additional `NodId`s and `DefId`s related to those additional items.
Treat custom enum discriminant values as constants
fixes#9882
changelog: All lints: Don't lint in enum discriminant values when the suggestion won't work in a const context
Lower them into a single item with multiple resolutions instead.
This also allows to remove additional `NodId`s and `DefId`s related to those additional items.
Don't lint `explicit_auto_deref` when the initial type is neither a reference, nor a receiver
fixes#9901fixes#9777
changelog: `explicit_auto_deref`: Don't lint when the initial value is neither a reference, nor a receiver
Don't cross contexts while building the suggestion for `redundant_closure_call`
fixes#9957
changelog: `redundant_closure_call`: Don't cross macro contexts while building the suggestion
Move `unnecessary_unsafety_doc` to `pedantic`
This lint was added in #9822. I like the idea, but also agree with #9986 as well. I think it should at least not be warn-by-default. This is one of these cases, where I'd like a group between pedantic and restriction. But I believe that users using `#![warn(clippy::pedantic)]` will know how to enable the lint if they disagree with it.
---
Since the lint is new:
changelog: none
r? `@flip1995` since I'd suggest back porting this, the original PR was merged 16 days ago.
Closes: #9986 (While it doesn't address everything, I believe that this is the best compromise)
Add allow-mixed-uninlined-format-args config
Implement `allow-mixed-uninlined-format-args` config param to change the behavior of the `uninlined_format_args` lint. Now it is a part of `style` per [Zulip chat](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/.60uninlined_format_args.60.20category), and won't propose inlining in case of a mixed usage, e.g. `print!("{} {}", var, 1+2)`. If the user sets `allow-mixed-uninlined-format-args` config param to `false`, the lint would behave like it did before -- proposing to inline args even in the mixed case.
---
changelog: [`uninlined_format_args`]: Added a new config `allow-mixed-uninlined-format-args` to allow the lint, if only some arguments can be inlined
[#9865](https://github.com/rust-lang/rust-clippy/pull/9865)
changelog: Moved [`uninlined_format_args`] to `style` (Now warn-by-default)
[#9865](https://github.com/rust-lang/rust-clippy/pull/9865)
Implement `allow-mixed-uninlined-format-args` config param to change the behavior of the `uninlined_format_args` lint. Now it is a part of `style`, and won't propose inlining in case of a mixed usage, e.g. `print!("{} {}", var, 1+2)`. If the user sets allow-mixed-uninlined-format-args config param to `false`, then it would behave like before, proposing to inline args even in the mixed case.
Previously, async constructs would be lowered to "normal" generators,
with an additional `from_generator` / `GenFuture` shim in between to
convert from `Generator` to `Future`.
The compiler will now special-case these generators internally so that
async constructs will *directly* implement `Future` without the need
to go through the `from_generator` / `GenFuture` shim.
The primary motivation for this change was hiding this implementation
detail in stack traces and debuginfo, but it can in theory also help
the optimizer as there is less abstractions to see through.
Add `clippy_utils::msrv::Msrv` to keep track of the current MSRV
changelog: Fix the scoping of the `#![clippy::msrv]` attribute
Fixes#6920
r? `@Jarcho`
Fix [`unnecessary_lazy_eval`] when type has significant drop
fix for https://github.com/rust-lang/rust-clippy/issues/9427#issuecomment-1295742590
However current implementation gives too many false positive, rending the lint almost useless.
I don't know what's the best way to check if a type has a "significant" drop (in the common meaning, not the internal rustc one, for example Option<(u8, u8)> should not be considered significant)
changelog: Fix [`unnecessary_lazy_eval`] when type has significant drop
Fix#9771 (`unnecessary_to_owned` false positive)
Fixes#9771
In that issue's example(s), the lint tried to add a `&` to a value, which implicitly changed the type of a field to a reference. The fix is to add the reference to `receiver_ty` (the type of the receiver of the `to_owned`-like method), before passing `receiver_ty` to `can_change_type`. `can_change_type` properly rejects the modified `receiver_ty`.
cc: `@mikerite` just because I think he was the author of `can_change_type`.
changelog: fix `unnecessary_to_owned` false positive which implicitly tried to change the type of a field to a reference
Fix `redundant_closure_for_method_calls` suggestion
Fixes#7746. The issue turns out to be more general than raw pointers. The `redundant_closure_for_method_calls` lint produces incorrect suggestions when the method is associated with a type that must be enclosed in angle brackets or must be written with generic arguments substituted. For example:
```rust
fn main() {
// Clippy's suggestion: [T; N]::as_slice
// Correct suggestion: <[u8; 3]>::as_slice
let array_opt: Option<&[u8; 3]> = Some(&[4, 8, 7]);
array_opt.map(|a| a.as_slice());
// Clippy's suggestion: [T]::len
// Correct suggestion: <[u8]>::len
let slice_opt: Option<&[u8]> = Some(b"slice");
slice_opt.map(|s| s.len());
// Clippy's suggestion: *const T::is_null
// Correct suggestion: <*const usize>::is_null
let ptr_opt: Option<*const usize> = Some(&487);
ptr_opt.map(|p| p.is_null());
// Clippy's suggestion: dyn TestTrait::method_on_dyn
// Correct suggestion: <dyn TestTrait>::method_on_dyn
let test_struct = TestStruct {};
let dyn_opt: Option<&dyn TestTrait> = Some(&test_struct);
dyn_opt.map(|d| d.method_on_dyn());
}
// For the trait object example:
trait TestTrait {}
struct TestStruct {}
impl TestTrait for TestStruct {}
impl dyn TestTrait + '_ {
fn method_on_dyn(&self) -> bool {
false
}
}
```
The issue also affects references and tuples, though I had to patch the standard library with non-trait methods for those types to test that. Just in case, I also included handling for `!`, since it appeared to be possible to call methods on it with angle brackets. I just couldn't verify the resulting suggestion, since dead-code analysis eliminates the code first.
This is my first exposure to Rust compiler internals, so please let me know if I'm taking the wrong approach here!
changelog: [`redundant_closure_for_method_calls`]: add angle brackets and substitute generic arguments in suggestion when needed
Add new lint [`misnamed-getters`]
```
changelog: Add new lint [`misnamed-getters`]
```
Closes#9769
The current lint matches all methods with a body of just one expression under the form `(&mut?)? <expr>.field` where field doesn't match the name of the method but there is a field of the same type in `<expr>` that matches the name. This allows matching nested structs, for example for newtype wrappers. This may cast the net a bit too wide and cause false positives. I'll run [clippy_lint_tester](https://github.com/mikerite/clippy_lint_tester) on the top crates to see how frequently false positives happen.
There also may be room for improvement by checking that the replacement field would work taking into account implementations of `Deref` and `DerefMut` even if the types don't exactly match but I don't know yet how this could be done.
[arithmetic-side-effects] Detect overflowing associated constants of integers
Triggers the negation of maximum unsigned integers using associated constants. Rustc already handles `-128i8` but doesn't handle `-i8::MAX`.
At the same time, allows stuff like `-1234`.
changelog: FP: [arithmetic-side-effects] Detect overflowing associated constants of integers
Keep original literal notation in suggestion
While I did some investigation of https://github.com/rust-lang/rust-clippy/issues/9866 (I couldn't reproduce it though) I found that `unused_rounding` formats as follows:
```rust
3.0_f64.round() // => 3.0f64
```
This PR makes them preserve as the original notation.
```rust
3.0_f64.round() // => 3.0_f64
```
changelog: Suggestion Enhancement: [`unused_rounding`]: The suggestion now preserves the original float literal notation
Return multiple resolutions from `def_path_res`
Changes `def_path_res` to return all the resolutions matching the path rather than the first one (with a namespace hint that covered some cases). This would fix any issues that come up with multiple versions of the same crate being present as they all have the same crate name
It also adds resolution of `impl _ {}` items for local items, and removes struct field resolution as it didn't seem to be used anywhere
I tested it on a local crate and it worked for the multiple crate issue, but I couldn't come up with a test that worked well with `// aux-build`, maybe `// aux-crate` after https://github.com/rust-lang/rust/pull/103266 could work but I'm not sure on that either
changelog: [`disallowed_methods`], [`disallowed_types`], [`disallowed_macros`]: fix path resolution with multiple versions of the same crate
changelog: [`disallowed_methods`]: Resolve methods in `impl`s in the current crate
Extend `needless_borrowed_reference` to structs and tuples, ignore _
changelog: [`needless_borrowed_reference`]: Lint struct and tuple patterns, and patterns containing `_`
Now lints patterns like
```rust
&(ref a, ref b)
&Tuple(ref a, ref b)
&Struct { ref a, ref b }
&(ref a, _)
```
Fix typo in `expect_used` and `unwrap_used` warning messages
"\`an Option\`" -> "an \`Option\`" and "\`a Result\`" -> "a \`Result\`".
changelog: fix typo in `expect_used` and `unwrap_used` warning messages
`never_loop`: don't emit AlwaysBreaks if it targets a block
ref: https://github.com/rust-lang/rust-clippy/pull/9837#issuecomment-1312788194
The previous fix (#9837) was too simple and ignored all break commands inside a labelled block, regardless of whether their destination was a labelled block or a loop. This fix tracks all the labelled blocks in scope to ensure that only breaks targeting loops are considered.
changelog: [`never_loop`]: prevent false negatives from `breaks` nested in labelled blocks
Clippy has an internal lint that checks for the usage of hardcoded def
paths and suggests to replace them with a lang or diagnostic item, if
possible. This was implemented with a hack, by getting all the variants
of the `LangItem` enum and then index into it with the position of the
`LangItem` in the `items` list. This is no longer possible, because the
`items` list can't be accessed anymore.
Introduced an ignored_ids parameter.
Takes O(n^2) time in the worst case.
Can be changed to collect block ids in first phase,
and then filter with binary search in second.
feat: lint unchecked subtraction of a 'Duration' from an 'Instant'
Hello all, I tried to tackle the open issue #9371 and this is what I came up with.
I have a difficulty currently - some tests are failing:
```
failures:
[ui] ui/manual_instant_elapsed.rs
```
The `manual_instant_elapsed` is failing because of `Instant::now() - duration` test, this now gets also picked by `unchecked_duration_subtraction` lint.
What is the correct way to proceed in this case? Simply update the `.stderr` file for `manual_instant_elapsed` lint?
changelog: [`unchecked_duration_subtraction`]: Add lint for unchecked subtraction of a `Duration` from an `Instant`.
fixes#9371
Make it clear that `or_fun_call` can be a false-positive
Also move it to nursery so that the false-positives can be dealt with.
CC #8574
changelog: [`or_fun_call`]: Mention false-positives, move to nursery.
Add `unnecessary_safety_doc` lint
changelog: [`unnecessary_safety_doc`]: Add `unnecessary_safety_doc` lint
fixes https://github.com/rust-lang/rust-clippy/issues/6880
This lint does not trigger for private functions, just like `missing_safety_docs`. Reason for that was implementation simplicity and because I figured asking first would make more sense, so if it should trigger for private functions as well let me know and I'll fix that up as well.
[`fn_params_excessive_bools`] Make it possible to allow the lint at the method level
changelog: FP: [`fn_params_excessive_bools`]: `#[allow]` now works on methods
fix https://github.com/rust-lang/rust-clippy/issues/9687
Tested without committing but `#[allow]`ing now works. Also rewrote the lint to be a late lint while at it :)
r? `@xFrednet`
Fix `explicit_auto_deref` fp
fixes#9763fixes#9811
changelog: `explicit_auto_deref`: Don't lint when the target type is a projection with generic arguments
Address issues 9739 and 9782
This PR fixes#9739 in the manner I suggested in https://github.com/rust-lang/rust-clippy/issues/9739#issuecomment-1296802376.
This PR also fixes the compilation failures in #9782 (but doesn't address `@e00E's` other objections).
Fixes#9739
r? `@Jarcho`
changelog: Fix two `needless_borrow` false positives, one involving borrows in `if`-`else`s, the other involving qualified function calls
Add `manual_is_ascii_check` lint
Addresses https://github.com/rust-lang/rust-clippy/issues/9290
This PR adds new lint `manual_is_ascii_check`, which detects comparison with ascii ranges using `matches!` macros.
As I mentioned as following in the Issue;
> Yes, that's true. we'll start small and then grow it.
> So I'll try to handle matches! macro with single range as suggested above.
However during writing first version, I was thinking that the changes to support alphabetic and digits will be small patch, so I made a single PR in hope review cost can be reduced.
changelog: add new lint [`manual_is_ascii_check`]
r? `@xFrednet`
Move needless_collect to nursery
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: [`needless_collect`]: Move `needless_collect` to nursery (Now allow-by-default)
After chatting with a few folks, it seems like `needless_collect` is giving false positives pretty regularly (https://github.com/rust-lang/rust-clippy/issues?q=is%3Aissue+is%3Aopen+needless_collect). We're big supporters of clippy in Nushell, and it's one of the passes we require for CI, but we've had to disable this particular lint. Perhaps it should be moved to the nursery until it's improved?
(apologies if this isn't the right approach to disabling a lint by default. I tried to follow the idea I saw other PRs doing in the past)
