Fixes to `manual_let_else`'s divergence check
A few changes to the divergence check in `manual_let_else` and moves it the implementation to `clippy_utils` since it's generally useful:
* Handle internal `break` and `continue` expressions.
e.g. The first loop is divergent, but the second is not.
```rust
{
loop {
break 'outer;
};
}
{
loop {
break;
};
}
```
* Match rust's definition of divergence which is defined via the type system.
e.g. The following is not considered divergent by rustc as the inner block has a result type of `()`:
```rust
{
'a: {
panic!();
break 'a;
};
}
```
* Handle when adding a single semicolon would make the expression divergent.
e.g. The following would be a divergent if a semicolon were added after the `if` expression:
```rust
{ if panic!() { 0 } else { 1 } }
```
changelog: None
Lint `needless_borrow` and `explicit_auto_deref` on most union field accesses
Changes both lints to follow rustc's rules around auto-deref through `ManuallyDrop` union fields rather than just bailing on union fields.
changelog: [`needless_borrow`] & [`explicit_auto_deref`]: Lint on most union field accesses
[`map_identity`]: respect match ergonomics
Fixes#11764
Note: the original tests before this were slightly wrong themselves already and had to be changed. They were calling `map` on an iterator of `&(i32, i32)`s, so this PR would stop linting there, but they were meant to test something else unrelated to binding modes, so I just changed them to remove the references so that it iterates over owned values and they all bind by value. This way they continue to test what they checked for before: the identity function for tuple patterns.
changelog: [`map_identity`]: respect match ergonomics
Replace if_chain with let chains
Closes#9353
Let chains are now supported by rustfmt 🎉
The PR is split into two commits
1. The result of running [`if-to-let-chain clippy*/**/*.rs`](https://github.com/Alexendoo/if-to-let-chain)
2. The manual clean up: fixing some errors/formatting, dogfood lints, removing the if_chain internal lint
r? `@flip1995`
changelog: none
Disable `vec_box` when using different allocators
Fixes#7114
This PR disables the `vec_box` lint when the `Box` and `Vec` use different allocators (but not when they use the same - custom - allocator).
For example - `Vec<Box<i32, DummyAllocator>>` will disable the lint, and `Vec<Box<i32, DummyAllocator>, DummyAllocator>` will not disable the lint.
In addition, the applicability of this lint has been changed to `Unspecified` due to the automatic fixes potentially breaking code such as the following:
```rs
fn foo() -> Vec<Box<i32>> { // -> Vec<i32>
vec![Box::new(1)]
}
```
It should be noted that the `if_chain->let-chains` fix has also been applied to this lint, so the diff does contain many changes.
changelog: disable `vec_box` lint when using nonstandard allocators
[`mod_module_files`] Don't emit lint for mod.rs in tests
fixes: #11775
current state: indiscriminately emits the lint for mod files in tests.
The following
```
tests/
common/
mod.rs
test.rs
```
is a common pattern for code shared across the tests and is suggested in the rust book. The change adds an additional check to verify that the mod file is not in tests.
changelog: Fix [`mod_module_files`]: false positive for mod files in tests folder
fixes: #11775
current state: indiscriminately emits the lint for mod files in tests.
The following
tests/
common/
mod.rs
test.rs
is a common pattern for code shared across the tests and is suggested in
the rust book. The change adds an additional check to verify that the
mod file is not in tests.
changelog: Fix [`mod_module_files`]: false positive for mod files in
tests folder
[arc_with_non_send_sync] Improve suggested resolution
Fixes: #11714
Improved the lint message for [`arc_with_non_send_sync`] to suggest using `RC` unless user needs an Arc, then suggests wrapping in a mutex, and then suggests implementing `Sync` and `Send`.
---
changelog: [`arc_with_non_send_sync`]: Suggest RC over unsafe impl of Send and Sync
Make SpanlessEq more consistent
1) Remove wildcard as requested in https://github.com/rust-lang/rust-clippy/issues/10267.
2) Implement `hir_utils::eq_expr` for `ExprKind::Closure`, `ExprKind::ConstBlock`, `ExprKind::InlineAsm` and `ExprKind::Yield`.
3) Reorder branches of `hir_utils::eq_expr` to be in alphabetical order.
---
changelog: none
update references of old `msrvs` and `conf` paths
In #11685, `clippy_lints::utils::conf` and `clippy_utils::msrvs` were moved to a separate `clippy_config` crate.
I noticed that not all references to those paths were updated, so this small PR intends to fix those.
changelog: none
[`unused_enumerate_index`]: don't ICE on empty tuples
Fixes#11755
changelog: [`unused_enumerate_index`]: don't ICE on empty tuples
I'm going to nominate for beta backport because the code that is needed to trigger this seems likely to occur in real code
`@rustbot` label +beta-nominated
Fix `dbg_macro` semi span calculation
`span_including_semi` was using a `BytePos` to index into a file's source which happened to work because the root file of the test started at `BytePos` 0, it didn't work for other files
changelog: none
Fix get_first false negative for VecDeque
fixes#11695
Also run the lint on `VecDeque` and suggest using `.front()` instead of `.get(0)` when trying to access the first element.
PS: At first I implemented the VecDeque Lint in a separate `if_chain` (see the previous commit).
Let me know if thats the preferred way, then I will remove the refactoring into one block.
changelog: [`get_first`]: fix false negative: Also lint `VecDeque` and suggest using `front()`
Add `unused_enumerate_index` lint
A lint for unused `.enumerate()` indexes (`for (_, x) in iter.enumerate()`).
I wasn't able to find a `rustc_span::sym::Enumerate`, so the code for checking that it's the correct `Enumerate` iterator is a bit weird.
---
changelog: New lint: [`unused_enumerate_index`]: A new lint for checking that the indexes from `.enumerate()` calls are used.
[#10404](https://github.com/rust-lang/rust-clippy/pull/10404)
<!-- changelog_checked -->
new lint: `unnecessary_fallible_conversions`
Closes#11577
A new lint that looks for calls such as `i64::try_from(1i32)` and suggests `i64::from(1i32)`. See lint description (and linked issue) for more details for why.
There's a tiny bit of overlap with the `useless_conversion` lint, in that the other one warns `T::try_from(T)` (i.e., fallibly converting to the same type), so this lint ignores cases like `i32::try_from(1i32)` to avoid emitting two warnings for the same expression.
Also, funnily enough, with this one exception, this lint would warn on exactly every case in the `useless_conversion_try` ui test that `useless_conversion` didn't cover (but never two warnings at the same time), which is neat. I did add an `#![allow]` though since we don't want interleaved warnings from multiple lints in the same uitest.
changelog: new lint: `unnecessary_fallible_conversions`
fix enum_variant_names depending lint depending on order
changelog: [`enum_variant_names`]: fix single word variants preventing lint of later variant pre/postfixed with the enum name
fixes#11494
Single word variants prevented checking the `check_enum_start` and `check_enum_end` for being run on later variants
