Peel blocks and statements utils
changelog: none
* Rename `remove_blocks` to `peel_blocks`
* Add `peel_blocks_and_stmts`
* Various refactors to use the above utils
* The utils also now check `block.rules`
Parenthesize blocks in `needless_bool` suggestion
Because the `if .. {}` statement already puts the condition in expression scope, contained blocks would be parsed as complete
statements, so any `&` binary expression whose left operand ended in a block would lead to a non-compiling suggestion.
We identify such expressions and add parentheses. Note that we don't make a difference between normal and unsafe blocks because the parsing problems are the same for both.
This fixes#8052.
---
changelog: none
Because the `if .. {}` statement already puts the condition in
expression scope, contained blocks would be parsed as complete
statements, so any `&` binary expression whose left operand ended in a
block would lead to a non-compiling suggestion.
This adds a visitor to identify such expressions and add parentheses.
This fixes#8052.
Fix some false negatives for [`single_char_pattern`]
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: Fix some false negatives for [`single_char_pattern`]
I noticed that clippy wasn't complaining about my usage of `split_once("x")` in a personal project so I updated the list of functions.
I had to update the test case for an unrelated issue because replace is now included in the list of functions to be linted.
Enable rustbot shortcuts for rust-clippy
This enables shortcuts for ``@rustbot`.` Just a quality of life feature for contributors.
|Shortcut| Full comment |
|---|---|
| ``@rustbot` ready` | ``@rustbot` label -S-waiting-on-author +S-waiting-on-review` |
| ``@rustbot` author` | ``@rustbot` label +S-waiting-on-author -S-waiting-on-review` |
See: https://github.com/rust-lang/triagebot/wiki/Shortcuts
The documentation also states that the author/assignee will be pinged. However, this doesn't seem to be the case, it at least hasn't done so for me and in this [PR](https://github.com/rust-lang/rust/pull/90642#issuecomment-962465404)
---
changelog: none
Consider NonNull as a pointer type
PR 1/2 for issue #8045. Add `NonNull` as a pointer class to suppress false positives like `UnsafeCell<NonNull<()>>`. However, this change is not sufficient to handle the cases shared in gtk-rs and Rug in the issue.
changelog: none
r? `@xFrednet`
Escape backslash in single_char_pattern.rs
Escape backslash in single_char_pattern.
Previously, the proposed clippy fix for a single backslash in raw strings ```r"\"``` or ```r#"\"#``` was also only an unescaped, *single* ```'\'```:
```shell
warning: single-character string constant used as pattern
2 | let s = r#"abc\xyz/"#.find(r"\");
| ^^^^ help: try using a `char` instead: `'\'`
|
= note: `#[warn(clippy::single_char_pattern)]` on by default
```
This PR corrects this to a properly escaped *double* backslash ```'\\'```.
I haven't come up with any other problematic cases, a single quote was already handled.
Closes: #8060
changelog: Escape backslash in ``[`single_char_pattern`]``
Fix `any()` not taking reference in `search_is_some` lint
`find` gives reference to the item, but `any` does not, so suggestion is broken in some specific cases.
Fixes: #7392
changelog: [`search_is_some`] Fix suggestion for `any()` not taking item by reference
Add test for pattern_type_mismatch.
This issue has been fixed by [commit](8c1c763c2d)
This PR is used for close #7946(Fixes#7946).
changelog: Add test for pattern_type_mismatch.
Improve `strlen_on_c_string`
fixes: #7436
changelog: lint `strlen_on_c_string` when used without a fully-qualified path
changelog: suggest removing the surrounding unsafe block for `strlen_on_c_string` when possible
Prior to PR #91205, checking for errors in the overall obligation
would check checking the `ParamEnv`, due to an incorrect
`super_visit_with` impl. With this bug fixed, we will now
bail out of impl candidate assembly if the `ParamEnv` contains
any error types.
In practice, this appears to be overly conservative - when an error
occurs early in compilation, we end up giving up early for some
predicates that we could have successfully evaluated without overflow.
By only checking for errors in the predicate itself, we avoid causing
additional spurious 'type annotations needed' errors after a 'real'
error has already occurred.
With this PR, the diagnostic changes caused by PR #91205 are reverted.
Add `needless_late_init` lint
examples:
```rust
let a;
a = 1;
// to
let a = 1;
```
```rust
let b;
match 3 {
0 => b = "zero",
1 => b = "one",
_ => b = "many",
}
// to
let b = match 3 {
0 => "zero",
1 => "one",
_ => "many",
};
```
```rust
let c;
if true {
c = 1;
} else {
c = -1;
}
// to
let c = if true {
1
} else {
-1
};
```
changelog: Add [`needless_late_init`]
