Removing the semicolon of the last statement of an expressionless block
may change the block type even if the statement's type is `()`. If the
block type is `!` because of a systematic early return, typing it as
`()` may make it incompatible with the expected type for the block (to
which `!` is cast).
Fix#14100
changelog: [`unnecessary_semicolon`]: do not remove semicolon if it
could change the block type from `!` to `()`
Commit 2550530266 has extended the
`precedence` lint to include bitmasking and shift operations. The lint
is warn by default, and this generates many hits, especially in embedded
or system code, where it is very idiomatic to use expressions such as `1
<< 3 | 1 << 5` without parentheses.
This commit splits the recent addition into a new lint, which is put
into the "restriction" category, while the original one stays in
"complexity", because mixing bitmasking and arithmetic operations is
less typical.
Fix#14097
changelog: [`precedence_bits`]: new lint
Commit 2550530266 has extended the
`precedence` lint to include bitmasking and shift operations. The lint
is warn by default, and this generates many hits, especially in embedded
or system code, where it is very idiomatic to use expressions such as
`1 << 3 | 1 << 5` without parentheses.
This commit splits the recent addition into a new lint, which is put
into the "restriction" category, while the original one stays in
"complexity", because mixing bitmasking and arithmetic operations is
less typical.
Removing the semicolon of the last statement of an expressionless block
may change the block type even if the statement's type is `()`. If the
block type is `!` because of a systematic early return, typing it as
`()` may make it incompatible with the expected type for the block (to
which `!` is cast).
fix#13959
The current implementation of the `write_literal` and `print_literal`
lint performs escaping for the second argument of `write!` ,`writeln!`,
`print!` and `println!` of the suggestion by first replacing `"` with
`\"`, and then replacing `\` with `\\`. Performing these replacements in
this order may lead to unnecessary backslashes being added if the
original code contains `"` (e.g. `"` -> `\\"`), potentially resulting in
a suggestion that causes the code to fail to compile.
In the issue mentioned above, it’s suggested to use raw strings as raw
strings, but implementing this would require an ad-hoc change to the
current implementation, so it has been deferred. (I'll implement this in
another PR)
changelog: [`write_literal`]: fix incorrect escaping of suggestions
changelog: [`print_literal`]: fix incorrect escaping of suggestions
Add a new lint `doc_overindented_list_items` to detect and fix list items
in docs that are overindented.
For example,
```rs
/// - first line
/// second line
fn foo() {}
```
this would be fixed to:
```rs
/// - first line
/// second line
fn foo() {}
```
This lint improves readabiliy and consistency in doc.
fix#14034
The currect implementation of `obfuscated_if_else` sometimes makes
incorrect suggestions when the original code have side effects (see the
example in the above issue). I think this can be fixed by changing the
applicability depending on whether it can have side effects or not.
changelog: [`obfuscated_if_else`]: change applicability when the
original code can have side effects
I opened https://github.com/rust-lang/rust-clippy/pull/13896 before.
However, I found that there're more cases where Clippy suggests to use
modules that belong to the `std` crate even in a `no_std` environment.
Therefore, this PR include the changes I've made in #13896 and new
changes to fix cases I found this time to prevent wrong suggestions in
`no_std` environments as well.
changelog: [`redundant_closure`]: correct suggestion in `no_std`
changelog: [`repeat_vec_with_capacity`]: correct suggestion in `no_std`
changelog: [`single_range_in_vec_init`]: don't emit suggestion to use
`Vec` in `no_std`
changelog: [`drain_collect`]: correct suggestion in `no_std`
changelog: [`map_with_unused_argument_over_ranges`]: correct suggestion
in `no_std`
also close#13895
Uplift `clippy::double_neg` lint as `double_negations`
Warns about cases like this:
```rust
fn main() {
let x = 1;
let _b = --x; //~ WARN use of a double negation
}
```
The intent is to keep people from thinking that `--x` is a prefix decrement operator. `++x`, `x++` and `x--` are invalid expressions and already have a helpful diagnostic.
I didn't add a machine-applicable suggestion to the lint because it's not entirely clear what the programmer was trying to achieve with the `--x` operation. The code that triggers the lint should always be reviewed manually.
Closes#82987
Receivers which are references to `Option` and `Result`, or who
implement `Deref` to one of those types, will be linted as well.
changelog: [`unnecessary_map_or`]: work with ref and `Deref` to `Option`
and `Result` as well
Fixes#14023
**Note:** this patch must be merged after #13998 – only the second
commit must be reviewed, the first one repeats the patch in #13998 for
mergeability reasons.
Get rid of `mir::Const::from_ty_const`
This function is strange, because it turns valtrees into `mir::Const::Value`, but the rest of the const variants stay as type system consts.
All of the callsites except for one in `instsimplify` (array length simplification of `ptr_metadata` call) just go through the valtree arm of the function, so it's easier to just create a `mir::Const` directly for those.
For the instsimplify case, if we have a type system const we should *keep* having a type system const, rather than turning it into a `mir::Const::Value`; it doesn't really matter in practice, though, bc `usize` has no padding, but it feels more principled.
part of https://github.com/rust-lang/rust-clippy/issues/9100
The `obfuscated_if_else` lint currently only triggers for the pattern
`.then_some(..).unwrap_or(..)`, but there're other cases where this lint
should be triggered, one of which is `.then(..).unwrap_or(..)`.
changelog: [`obfuscated_if_else`]: trigger lint for the
`.then(..).unwrap_or(..)` pattern as well
changelog: none
`x & 15 == 0` is not equivalent to `x.trailing_zeros() > 4`, as `x =
0b10000` is true for the former and false for the latter.
In fact, clippy itself suggests the following:
```rust
pub fn src(x: i32) -> bool {
x & 15 == 0 // ~error: bit mask could be simplified with a call to `trailing_zeros`
^^^^^^^^^^^ help: try: `x.trailing_zeros() >= 4`
}
```
I ran across this message while writing code and thought it was quite
odd. I've simplified it and hopefully made it clearer for non-native
English speakers.
changelog: clarify message for non-obvious precedence
