This requires making the `deref_addrof` lint a late lint instead of an
early lint to check for types.
changelog: [`deref_addrof`]: do not suggest implicit `DerefMut` on
`ManuallyDrop` union fields
Fixrust-lang/rust-clippy#14386
fixesrust-lang/rust-clippy#14869
Added a simple check if both chars are of length 3
If they are, we skip the check for that pair.
This won't handle the 4 v 3 case.
Not sure if this was the intent of the issue.
Also saw we have some hardcoded exemptions for `set, get` and `lhs, rhs`
Tried removing them thinking they would be handled by the new condition.
But we have to keep because they allow for `bla_lhs` v `bla_rhs` to be
skipped
changelog:[`similar_names`]: Stop triggering for 3-character names
this could arguably be 2 separate PRs, but both of these were brought up
in the same issue, so..
fixes https://github.com/rust-lang/rust-clippy/issues/15398
- [x] I'm a bit doubtful about the last commit -- see the message for my
reasoning and do let me know whether it's right.
changelog: [`borrow_as_ptr`]: don't lint inside proc-macros
changelog: [`ptr_as_ptr`]: don't lint inside proc-macros
Change the desugaring of `assert!` for better error output
In the desugaring of `assert!`, we now expand to a `match` expression instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
Now `assert!(val)` desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix#122159.
In the desugaring of `assert!`, we now expand to a `match` expression
instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not
the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
`assert!(val)` now desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix#122159.
We make some minor changes to some diagnostics to avoid span overlap on
type mismatch or inverted "expected"/"found" on type errors.
We remove some unnecessary parens from core, alloc and miri.
address review comments
Account for new `assert!` desugaring in `!condition` suggestion
`rustc` in https://github.com/rust-lang/rust/pull/122661 is going to change the desugaring of `assert!` to be
```rust
match condition {
true => {}
_ => panic!(),
}
```
which will make the edge-case of `condition` being `impl Not<Output = bool>` while not being `bool` itself no longer a straightforward suggestion, but `!!condition` will coerce the expression to be `bool`, so it can be machine applicable.
Transposing https://github.com/rust-lang/rust-clippy/pull/15453/ to the rustc repo.
r? `````@samueltardieu`````
`rustc` is going to change the desugaring of `assert!` to be
```rust
match condition {
true => {}
_ => panic!(),
}
```
which will make the edge-case of `condition` being `impl Not<Output = bool>`
while not being `bool` itself no longer a straightforward suggestion,
but `!!condition` will coerce the expression to be `bool`, so it can be
machine applicable.
minor fix in `from_str_radix_10` lint, `is_type_diagnostic_item` only
checks `Adt`, use `.is_str()` instead
changelog: [`from_str_radix_10`]: properly lint references to `&str` as
well
combine two similar arms
use in `eager_transmute`
use in `double_ended_iterator_last`
use different numbers in the new test case to avoid possible confusion
move the other "unfixable" case as well; it shouldn't lint anyway, so
having it in the main test file is fine
changelog: [infinite_loop]: Improve handling of infinite loops in async
blocks
Fixrust-lang/rust-clippy#14000
This PR refines the [infinite_loop] lint to avoid false positives when
infinite loops occur inside async blocks that are not awaited (such as
those that are spawned or assigned to variables for later use). The lint
will now only trigger when the async block containing the loop is
directly awaited.
changelog: [`collapsible_else_if`]: fix suggestion when inner `if` as
wrapped in parentheses
changelog: [`collapsible_if`]: fix suggestion when inner `if` as wrapped
in parentheses
fixes https://github.com/rust-lang/rust-clippy/issues/15303
I'm sure this is a bit dirty, but don't currently see a better way.
The `unnecessary_sort_by` lint displays different method names in
message and suggestion, which is a bit confusing.
Also got a question about `UNNECESSARY_SORT_BY` lint definition. Should
we extend its message to also cover *_unstable_* methods?
changelog: [`unnecessary-sort-by`]: sort method consistency in message
and suggestion
Philipp Krones