Fix FP in inherent_to_string when the function has generic parameters
Minimal example of the false positive:
````
struct G;
impl G {
fn to_string<const _N: usize>(&self) -> String {
"G.to_string()".to_string()
}
}
fn main() {
let g = G;
g.to_string::<1>();
}
````
Clippy emits an `inherent_to_string` warning, and suggests that we implement `Display` for `G` instead. However, this is not possible, since the generic parameter _N only exists in this function, not in `G` itself. This particular example uses const generics, which is where the issue is most likely to come up, but this PR skips the lint if the `to_string` function has any kind of generic parameters.
changelog: Fix FP in `inherent_to_string`
Change unnecessary_wraps to pedantic
changelog: Change unnecessary_wraps to pedantic
There seems to be enough evidence that this lint is not wanted as warn-by-default. Attempted before at #6380. False positives at #6721 and #6427. Actually requested to change the category at #6726.
Closes#6726
Teach SpanlessEq binding IDs
changelog: Fix collapsible_match false positive
Fixes#6740
This PR changes the way `SpanlessEq` determines whether two local variables are the same. Instead of checking that the names match, it checks that the `HirId`s match. If local bindings are declared within the expressions that are being compared, `SpanlessEq` will remember bindings that correspond to each other in a `FxHashMap<HirId, HirId>`. This makes `SpanlessEq` more flexible while also fixing false positives.
Example: `{ let x = 1; x + 2 }` is equal to `{ let y = 1; y + 2 }`.
CC `@xFrednet` I think this will resolve some concerns in #6463
Add the from_str_radix_10 lint
changelog: added the new `from_str_radix_10` which sometimes replaces calls to `primitive::from_str_radix` to `str::parse`
This is ready to be merged, although maybe the category should be `pedantic` instead of `style`? I'm not sure where it fits better.
Closes#6713.
collapsible_match: fix lint message capitalization
(see https://rustc-dev-guide.rust-lang.org/diagnostics.html for details)
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: collapsible_match: fix lint message capitalization
lintcheck: parallelize
By default we use a single thread and one target dir as before.
If `-j n` is passed, use `n` target dirs and run one clippy in each of them.
We need several target dirs because cargo would lock them for a single process otherwise which would prevent the parallelism.
`-j 0` makes rayon use $thread_count/2 (which I assume is the number of physical cores of a machine) for the number of threads.
Other change:
Show output of clippy being compiled when building it for lintcheck (makes it easier to spot compiler errors etc)
Show some progress indication in the "Linting... foo 1.2.3" message.
Sort crates before linting (previously crates would be split randomly between target dirs, with the sorting, we try to make sure that even crates land in target dir 0 and odd ones in target dir 1 etc..)
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: parallelize lintcheck with rayon
ast: Keep expansion status for out-of-line module items
I.e. whether a module `mod foo;` is already loaded from a file or not.
This is a pre-requisite to correctly treating inner attributes on such modules (https://github.com/rust-lang/rust/issues/81661).
With this change AST structures for `mod` items diverge even more for AST structure for the crate root, which previously used `ast::Mod`.
Therefore this PR removes `ast::Mod` from `ast::Crate` in the first commit, these two things are sufficiently different from each other, at least at syntactic level.
Customization points for visiting a "`mod` item or crate root" were also removed from AST visitors (`fn visit_mod`).
`ast::Mod` itself was refactored away in the second commit in favor of `ItemKind::Mod(Unsafe, ModKind)`.
Use rayon to figure out the threadcount and half that for core count.
For each core, create a target dir that is used.
Otherwise, when running multiple clippys with the same target-dir, cargo would lock the dir and prevent parallelism.
This way we can run multiple clippys at the same time (on root crates) but we sacrifice cache-hits (when we already cargo-checked crate-deps).
Fix for issue 6640
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: unnecessary_wraps will now suggest to remove unnecessary wrapped return unit type, like Option<()>
fixes#6640
Fix lintcheck by excluding checked crates from workspace
r? `@matthiaskrgr` cc `@camsteffen`
So `exclude` doesn't work with glob patterns, but it turns out that it works with `starts_with`.
changelog: none
Replace if-let and while-let with `if let` and `while let`
This pull request replaces if-let and while-let with `if let` and `while let`.
closes https://github.com/rust-lang/rust/issues/82205
Lintcheck and an options for command line options
Make it possible to add command line options to the clippy invocation of the lintcheck-tool
changelog: none
r? `@matthiaskrgr`
I found that this will be really helpful if we use a separate repository and want to maintain a all-lints-passing list of crates. See my early experimentation here: https://github.com/flip1995/clippy-lintcheck
```
git submodule update --init
cargo run -- --mode=all
```
Will run the lintcheck tool on all the specified crates in `config/` in that repository.
New lint: default_numeric_fallback
fixes#6064
r? `@flip1995`
As we discussed in [here](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Issue.20.236064/near/224647188) and [here](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Issue.20clippy.236064/near/224746333), I start implementing this lint from the strictest version.
In this PR, I'll allow the below two cases to pass the lint to reduce FPs.
1. Appearances of unsuffixed numeric literals in `Local` if `Local` has a type annotation, for example:
```rust
// Good.
let x: i32 = 1;
// Also good.
let x: (i32, i32) = if cond {
(1, 2)
} else {
(2, 3)
};
```
2. Appearances of unsuffixed numeric literals in args of `Call` or `MethodCall` if corresponding arguments of their signature have concrete types, for example:
```rust
fn foo_mono(x: i32) -> i32 {
x
}
fn foo_poly<T>(t: T) -> t {
t
}
// Good.
let x = foo_mono(13);
// Still bad.
let x: i32 = foo_poly(13);
```
changelog: Added restriction lint: `default_numeric_fallback`
