Don't suggest an empty variant name in `enum_variant_names`
changelog: false positive fix: [`enum_variant_names`]: No longer suggests an empty variant name
Fixes#8324
This commit changes the behavior of `single_match` lint.
After that, we won't lint non-exhaustive matches like this:
```rust
match Some(v) {
Some(a) => println!("${:?}", a),
None => {},
}
```
The rationale is that, because the type of `a` could be changed, so the
user can get non-exhaustive match after applying the suggested lint (see
https://github.com/rust-lang/rust-clippy/issues/8282#issuecomment-1013566068
for context).
We also will lint `match` constructions with tuples. When we see the
tuples on the both arms, we will check them both at the same time, and
if they form exhaustive match, we could display the warning.
Closes#8282
This is the same idea as #92533, but for `AssocItem` instead
of `VariantDef`/`FieldDef`.
With this change, we no longer have any uses of
`#[stable_hasher(project(...))]`
Add `msrv` config for `map_clone`
Just a small PR to have some fun with Clippy and to clear my head a bit 😅
---
changelog: [`map_clone`]: The suggestion takes `msrv` into account
changelog: Track `msrv` attribute for `manual_bits` and `borrow_as_prt`
fixes: #8276
Out of cycle Clippy update
I want to do an out-of-cycle sync for rust-lang/rust-clippy#8295, and possibly backport this to stable together with https://github.com/rust-lang/rust/issues/92938. If this doesn't get backported to stable, then I at least want to backport it to beta.
r? `@Manishearth`
fix op_ref false positive
fixes#7572
changelog: `op_ref` don't lint for unnecessary reference in BinOp impl if removing the reference will lead to unconditional recursion
Replace use of `ty()` on term and use it in more places. This will allow more flexibility in the
future, but slightly worried it allows items which are consts which only accept types.
ProjectionPredicate should be able to handle both associated types and consts so this adds the
first step of that. It mainly just pipes types all the way down, not entirely sure how to handle
consts, but hopefully that'll come with time.
Replace `NestedVisitorMap` with generic `NestedFilter`
This is an attempt to make the `intravisit::Visitor` API simpler and "more const" with regard to nested visiting.
With this change, `intravisit::Visitor` does not visit nested things by default, unless you specify `type NestedFilter = nested_filter::OnlyBodies` (or `All`). `nested_visit_map` returns `Self::Map` instead of `NestedVisitorMap<Self::Map>`. It panics by default (unreachable if `type NestedFilter` is omitted).
One somewhat trixty thing here is that `nested_filter::{OnlyBodies, All}` live in `rustc_middle` so that they may have `type Map = map::Map` and so that `impl Visitor`s never need to specify `type Map` - it has a default of `Self::NestedFilter::Map`.
issue #8239: Printed hint for lint or_fun_call is cropped and does no…
fixesrust-lang/rust-clippy#8239
changelog: [`or_fun_call`]: if suggestion contains more lines than MAX_SUGGESTION_HIGHLIGHT_LINES it is stripped to one line
Remove deprecated LLVM-style inline assembly
The `llvm_asm!` was deprecated back in #87590 1.56.0, with intention to remove
it once `asm!` was stabilized, which already happened in #91728 1.59.0. Now it
is time to remove `llvm_asm!` to avoid continued maintenance cost.
Closes#70173.
Closes#92794.
Closes#87612.
Closes#82065.
cc `@rust-lang/wg-inline-asm`
r? `@Amanieu`
Handle implicit named arguments in `useless_format`
fixes#8290
Ideally this would fix the macro parsing code to handle this, but this is a smaller change and easier to back port.
changelog: Handle implicit named arguments in `useless_format`
Update copyright year for Clippy (2022 edition)
At this point, I'm just searching for small things to do instead of sleeping or working on my bachelor thesis. 😅 Taking one day off will be fine 🙃
changelog: none
Update rayon and rustc-rayon
This updates rayon for various tools and rustc-rayon for the compiler's parallel mode.
- rayon v1.3.1 -> v1.5.1
- rayon-core v1.7.1 -> v1.9.1
- rustc-rayon v0.3.1 -> v0.3.2
- rustc-rayon-core v0.3.1 -> v0.3.2
... and indirectly, this updates all of crossbeam-* to their latest versions.
Fixes#92677 by removing crossbeam-queue, but there's still a lingering question about how tidy discovers "runtime" dependencies. None of this is truly in the standard library's dependency tree at all.