Quick fix cargo dev bless
fixes#6757
r? `@phansch`
Trying to do a quick fix of `bless`, I'm not sure how much work it will need to do transition to `bless` built in `compiletest`, so please feel free to close this PR if it will not need so much.
changelog: none
upper_case_acronyms: move lint from style to pedantic lint group
The lint does point out inconsistency with the Rust naming convention,
but the fact that rustc does not warn about the inconsistency by default
means that clippy probably should not warn by default either.
changelog: move upper_case_acronyms lint from style to pedantic group.
The lint does point out inconsistency with the Rust naming convention,
but the fact that rustc does not warn about the inconsistency by default
means that clippy probably should not warn by default either.
changelog: move upper_case_acronyms lint from style to pedantic group.
Inconsistent struct constructor
fixes: #6352
r? `@matthiaskrgr`
I added the lint that checks for the struct constructors where the order of the field init shorthands is inconsistent with that in the struct definition.
changelog: Add style lint: `inconsistent_struct_constructor`
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
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
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`
