2022-05-04 18:13:06 +01:00
|
|
|
#![warn(clippy::identity_op)]
|
2022-10-02 15:13:22 -04:00
|
|
|
#![allow(unused)]
|
2022-05-04 18:13:06 +01:00
|
|
|
#![allow(
|
|
|
|
|
clippy::eq_op,
|
|
|
|
|
clippy::no_effect,
|
|
|
|
|
clippy::unnecessary_operation,
|
|
|
|
|
clippy::op_ref,
|
|
|
|
|
clippy::double_parens,
|
2023-12-30 13:25:33 +02:00
|
|
|
clippy::uninlined_format_args,
|
|
|
|
|
clippy::borrow_deref_ref,
|
|
|
|
|
clippy::deref_addrof
|
2022-05-04 18:13:06 +01:00
|
|
|
)]
|
|
|
|
|
|
|
|
|
|
use std::fmt::Write as _;
|
|
|
|
|
|
|
|
|
|
const ONE: i64 = 1;
|
|
|
|
|
const NEG_ONE: i64 = -1;
|
|
|
|
|
const ZERO: i64 = 0;
|
|
|
|
|
|
|
|
|
|
struct A(String);
|
|
|
|
|
|
|
|
|
|
impl std::ops::Shl<i32> for A {
|
|
|
|
|
type Output = A;
|
|
|
|
|
fn shl(mut self, other: i32) -> Self {
|
|
|
|
|
let _ = write!(self.0, "{}", other);
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct Length(u8);
|
|
|
|
|
struct Meter;
|
|
|
|
|
|
|
|
|
|
impl core::ops::Mul<Meter> for u8 {
|
|
|
|
|
type Output = Length;
|
|
|
|
|
fn mul(self, _: Meter) -> Length {
|
|
|
|
|
Length(self)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[rustfmt::skip]
|
|
|
|
|
fn main() {
|
|
|
|
|
let x = 0;
|
|
|
|
|
|
|
|
|
|
x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
x + 1;
|
|
|
|
|
x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
1 + x;
|
|
|
|
|
x - ZERO; //no error, as we skip lookups (for now)
|
|
|
|
|
x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
((ZERO)) | x; //no error, as we skip lookups (for now)
|
|
|
|
|
|
|
|
|
|
x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
x / ONE; //no error, as we skip lookups (for now)
|
|
|
|
|
|
|
|
|
|
x / 2; //no false positive
|
|
|
|
|
|
|
|
|
|
x & NEG_ONE; //no error, as we skip lookups (for now)
|
|
|
|
|
x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
|
|
|
|
|
let u: u8 = 0;
|
|
|
|
|
u;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
|
|
|
|
|
1 << 0; // no error, this case is allowed, see issue 3430
|
|
|
|
|
42;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
1;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
42;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-11-30 16:25:57 -05:00
|
|
|
x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
|
2022-08-05 20:59:50 -03:00
|
|
|
let mut a = A(String::new());
|
2022-05-04 18:13:06 +01:00
|
|
|
let b = a << 0; // no error: non-integer
|
|
|
|
|
|
|
|
|
|
1 * Meter; // no error: non-integer
|
|
|
|
|
|
|
|
|
|
2;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
-2;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
2 + x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
-2 + x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
x + 1;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
(x + 1) % 3; // no error
|
|
|
|
|
4 % 3; // no error
|
|
|
|
|
4 % -3; // no error
|
|
|
|
|
|
|
|
|
|
// See #8724
|
|
|
|
|
let a = 0;
|
|
|
|
|
let b = true;
|
|
|
|
|
(if b { 1 } else { 2 });
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
(if b { 1 } else { 2 }) + if b { 3 } else { 4 };
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
(match a { 0 => 10, _ => 20 });
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
(match a { 0 => 10, _ => 20 }) + match a { 0 => 30, _ => 40 };
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
(if b { 1 } else { 2 }) + match a { 0 => 30, _ => 40 };
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
(match a { 0 => 10, _ => 20 }) + if b { 3 } else { 4 };
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2024-11-07 20:45:15 -08:00
|
|
|
((if b { 1 } else { 2 }));
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
|
|
|
|
|
({ a }) + 3;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
({ a } * 2);
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
(loop { let mut c = 0; if c == 10 { break c; } c += 1; }) + { a * 2 };
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
|
|
|
|
|
fn f(_: i32) {
|
|
|
|
|
todo!();
|
|
|
|
|
}
|
2023-12-30 13:25:33 +02:00
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
f(a + { 8 * 5 });
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
f(if b { 1 } else { 2 } + 3);
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2024-02-28 13:17:14 +00:00
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
const _: i32 = { 2 * 4 } + 3;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
const _: i32 = { 1 + 2 * 3 } + 3;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
|
|
|
|
|
a as usize;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
let _ = a as usize;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
({ a } as usize);
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
|
|
|
|
|
2 * { a };
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2024-11-07 20:45:15 -08:00
|
|
|
(({ a } + 4));
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
1;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-11-30 16:25:57 -05:00
|
|
|
|
|
|
|
|
// Issue #9904
|
|
|
|
|
let x = 0i32;
|
|
|
|
|
let _: i32 = x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2022-05-04 18:13:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub fn decide(a: bool, b: bool) -> u32 {
|
|
|
|
|
(if a { 1 } else { 2 }) + if b { 3 } else { 5 }
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
2022-05-04 18:13:06 +01:00
|
|
|
}
|
2023-12-30 13:25:33 +02:00
|
|
|
|
|
|
|
|
/// The following tests are from / for issue #12050
|
|
|
|
|
/// In short, the lint didn't work for coerced references,
|
|
|
|
|
/// e.g. let x = &0; let y = x + 0;
|
|
|
|
|
/// because the suggested fix was `let y = x;` but
|
|
|
|
|
/// it should have been `let y = *x;`
|
|
|
|
|
fn issue_12050() {
|
|
|
|
|
{
|
|
|
|
|
let x = &0i32;
|
|
|
|
|
let _: i32 = *x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2023-12-30 13:25:33 +02:00
|
|
|
let _: i32 = *x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
2023-12-30 13:25:33 +02:00
|
|
|
}
|
|
|
|
|
{
|
|
|
|
|
let x = &&0i32;
|
|
|
|
|
let _: i32 = **x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2023-12-30 13:25:33 +02:00
|
|
|
let x = &&0i32;
|
|
|
|
|
let _: i32 = **x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
2023-12-30 13:25:33 +02:00
|
|
|
}
|
|
|
|
|
{
|
|
|
|
|
// this is just silly
|
|
|
|
|
let x = &&&0i32;
|
|
|
|
|
let _: i32 = ***x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2023-12-30 13:25:33 +02:00
|
|
|
let _: i32 = ***x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2023-12-30 13:25:33 +02:00
|
|
|
let x = 0i32;
|
|
|
|
|
let _: i32 = *&x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2023-12-30 13:25:33 +02:00
|
|
|
let _: i32 = **&&x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2023-12-30 13:25:33 +02:00
|
|
|
let _: i32 = *&*&x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2023-12-30 13:25:33 +02:00
|
|
|
let _: i32 = **&&*&x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
2023-12-30 13:25:33 +02:00
|
|
|
}
|
|
|
|
|
{
|
|
|
|
|
// this is getting ridiculous, but we should still see the same
|
|
|
|
|
// error message so let's just keep going
|
|
|
|
|
let x = &0i32;
|
|
|
|
|
let _: i32 = ***&&*&x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2023-12-30 13:25:33 +02:00
|
|
|
let _: i32 = ***&&*&x;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
2023-12-30 13:25:33 +02:00
|
|
|
}
|
|
|
|
|
}
|
fix: `identity_op` suggestions use correct parenthesis
The `identity_op` lint was suggesting code fixes that resulted
in incorrect or broken code, due to missing parenthesis in the fix
that changed the semantics of the code.
For a binary expression, `left op right`, if the `left` was redundant,
it would check if the right side needed parenthesis, but if the `right`
was redundant, it would just assume that the left side did not need
parenthesis.
This can result in either rustfix generating broken code and failing,
or code that has different behavior than before the fix.
e.g. `-(x + y + 0)` would turn into `-x + y`, changing the behavior,
and `1u64 + (x + y + 0i32) as u64` where `x: i32` and `y: i32` would
turn into `1u64 + x + y as u64`, creating broken code where `x` cannot
be added to the other values, as it was never cast to `u64`.
This commit fixes both of these cases by always checking the
non-redundant child of a binary expression for needed parenthesis, and
makes it so if we need parenthesis, but they already exist, we don't add
any redundant ones.
Fixes #13470
2024-11-02 19:47:11 -07:00
|
|
|
|
|
|
|
|
fn issue_13470() {
|
|
|
|
|
let x = 1i32;
|
|
|
|
|
let y = 1i32;
|
|
|
|
|
// Removes the + 0i32 while keeping the parentheses around x + y so the cast operation works
|
|
|
|
|
let _: u64 = (x + y) as u64;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
fix: `identity_op` suggestions use correct parenthesis
The `identity_op` lint was suggesting code fixes that resulted
in incorrect or broken code, due to missing parenthesis in the fix
that changed the semantics of the code.
For a binary expression, `left op right`, if the `left` was redundant,
it would check if the right side needed parenthesis, but if the `right`
was redundant, it would just assume that the left side did not need
parenthesis.
This can result in either rustfix generating broken code and failing,
or code that has different behavior than before the fix.
e.g. `-(x + y + 0)` would turn into `-x + y`, changing the behavior,
and `1u64 + (x + y + 0i32) as u64` where `x: i32` and `y: i32` would
turn into `1u64 + x + y as u64`, creating broken code where `x` cannot
be added to the other values, as it was never cast to `u64`.
This commit fixes both of these cases by always checking the
non-redundant child of a binary expression for needed parenthesis, and
makes it so if we need parenthesis, but they already exist, we don't add
any redundant ones.
Fixes #13470
2024-11-02 19:47:11 -07:00
|
|
|
// both of the next two lines should look the same after rustfix
|
|
|
|
|
let _: u64 = 1u64 & (x + y) as u64;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
fix: `identity_op` suggestions use correct parenthesis
The `identity_op` lint was suggesting code fixes that resulted
in incorrect or broken code, due to missing parenthesis in the fix
that changed the semantics of the code.
For a binary expression, `left op right`, if the `left` was redundant,
it would check if the right side needed parenthesis, but if the `right`
was redundant, it would just assume that the left side did not need
parenthesis.
This can result in either rustfix generating broken code and failing,
or code that has different behavior than before the fix.
e.g. `-(x + y + 0)` would turn into `-x + y`, changing the behavior,
and `1u64 + (x + y + 0i32) as u64` where `x: i32` and `y: i32` would
turn into `1u64 + x + y as u64`, creating broken code where `x` cannot
be added to the other values, as it was never cast to `u64`.
This commit fixes both of these cases by always checking the
non-redundant child of a binary expression for needed parenthesis, and
makes it so if we need parenthesis, but they already exist, we don't add
any redundant ones.
Fixes #13470
2024-11-02 19:47:11 -07:00
|
|
|
// Same as above, but with extra redundant parenthesis
|
2024-11-07 20:45:15 -08:00
|
|
|
let _: u64 = 1u64 & ((x + y)) as u64;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
fix: `identity_op` suggestions use correct parenthesis
The `identity_op` lint was suggesting code fixes that resulted
in incorrect or broken code, due to missing parenthesis in the fix
that changed the semantics of the code.
For a binary expression, `left op right`, if the `left` was redundant,
it would check if the right side needed parenthesis, but if the `right`
was redundant, it would just assume that the left side did not need
parenthesis.
This can result in either rustfix generating broken code and failing,
or code that has different behavior than before the fix.
e.g. `-(x + y + 0)` would turn into `-x + y`, changing the behavior,
and `1u64 + (x + y + 0i32) as u64` where `x: i32` and `y: i32` would
turn into `1u64 + x + y as u64`, creating broken code where `x` cannot
be added to the other values, as it was never cast to `u64`.
This commit fixes both of these cases by always checking the
non-redundant child of a binary expression for needed parenthesis, and
makes it so if we need parenthesis, but they already exist, we don't add
any redundant ones.
Fixes #13470
2024-11-02 19:47:11 -07:00
|
|
|
// Should maintain parenthesis even if the surrounding expr has the same precedence
|
2024-11-07 20:45:15 -08:00
|
|
|
let _: u64 = 5u64 + ((x + y)) as u64;
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
fix: `identity_op` suggestions use correct parenthesis
The `identity_op` lint was suggesting code fixes that resulted
in incorrect or broken code, due to missing parenthesis in the fix
that changed the semantics of the code.
For a binary expression, `left op right`, if the `left` was redundant,
it would check if the right side needed parenthesis, but if the `right`
was redundant, it would just assume that the left side did not need
parenthesis.
This can result in either rustfix generating broken code and failing,
or code that has different behavior than before the fix.
e.g. `-(x + y + 0)` would turn into `-x + y`, changing the behavior,
and `1u64 + (x + y + 0i32) as u64` where `x: i32` and `y: i32` would
turn into `1u64 + x + y as u64`, creating broken code where `x` cannot
be added to the other values, as it was never cast to `u64`.
This commit fixes both of these cases by always checking the
non-redundant child of a binary expression for needed parenthesis, and
makes it so if we need parenthesis, but they already exist, we don't add
any redundant ones.
Fixes #13470
2024-11-02 19:47:11 -07:00
|
|
|
// If we don't maintain the parens here, the behavior changes
|
|
|
|
|
let _ = -(x + y);
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2024-11-04 19:19:58 -08:00
|
|
|
// Similarly, we need to maintain parens here
|
|
|
|
|
let _ = -(x / y);
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
fix: `identity_op` suggestions use correct parenthesis
The `identity_op` lint was suggesting code fixes that resulted
in incorrect or broken code, due to missing parenthesis in the fix
that changed the semantics of the code.
For a binary expression, `left op right`, if the `left` was redundant,
it would check if the right side needed parenthesis, but if the `right`
was redundant, it would just assume that the left side did not need
parenthesis.
This can result in either rustfix generating broken code and failing,
or code that has different behavior than before the fix.
e.g. `-(x + y + 0)` would turn into `-x + y`, changing the behavior,
and `1u64 + (x + y + 0i32) as u64` where `x: i32` and `y: i32` would
turn into `1u64 + x + y as u64`, creating broken code where `x` cannot
be added to the other values, as it was never cast to `u64`.
This commit fixes both of these cases by always checking the
non-redundant child of a binary expression for needed parenthesis, and
makes it so if we need parenthesis, but they already exist, we don't add
any redundant ones.
Fixes #13470
2024-11-02 19:47:11 -07:00
|
|
|
// Maintain parenthesis if the parent expr is of higher precedence
|
|
|
|
|
let _ = 2i32 * (x + y);
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
2024-11-03 09:23:03 -08:00
|
|
|
// Maintain parenthesis if the parent expr is the same precedence
|
|
|
|
|
// as not all operations are associative
|
|
|
|
|
let _ = 2i32 - (x - y);
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
fix: `identity_op` suggestions use correct parenthesis
The `identity_op` lint was suggesting code fixes that resulted
in incorrect or broken code, due to missing parenthesis in the fix
that changed the semantics of the code.
For a binary expression, `left op right`, if the `left` was redundant,
it would check if the right side needed parenthesis, but if the `right`
was redundant, it would just assume that the left side did not need
parenthesis.
This can result in either rustfix generating broken code and failing,
or code that has different behavior than before the fix.
e.g. `-(x + y + 0)` would turn into `-x + y`, changing the behavior,
and `1u64 + (x + y + 0i32) as u64` where `x: i32` and `y: i32` would
turn into `1u64 + x + y as u64`, creating broken code where `x` cannot
be added to the other values, as it was never cast to `u64`.
This commit fixes both of these cases by always checking the
non-redundant child of a binary expression for needed parenthesis, and
makes it so if we need parenthesis, but they already exist, we don't add
any redundant ones.
Fixes #13470
2024-11-02 19:47:11 -07:00
|
|
|
// But make sure that inner parens still exist
|
|
|
|
|
let z = 1i32;
|
2024-11-07 20:45:15 -08:00
|
|
|
let _ = 2 + (x + (y * z));
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
fix: `identity_op` suggestions use correct parenthesis
The `identity_op` lint was suggesting code fixes that resulted
in incorrect or broken code, due to missing parenthesis in the fix
that changed the semantics of the code.
For a binary expression, `left op right`, if the `left` was redundant,
it would check if the right side needed parenthesis, but if the `right`
was redundant, it would just assume that the left side did not need
parenthesis.
This can result in either rustfix generating broken code and failing,
or code that has different behavior than before the fix.
e.g. `-(x + y + 0)` would turn into `-x + y`, changing the behavior,
and `1u64 + (x + y + 0i32) as u64` where `x: i32` and `y: i32` would
turn into `1u64 + x + y as u64`, creating broken code where `x` cannot
be added to the other values, as it was never cast to `u64`.
This commit fixes both of these cases by always checking the
non-redundant child of a binary expression for needed parenthesis, and
makes it so if we need parenthesis, but they already exist, we don't add
any redundant ones.
Fixes #13470
2024-11-02 19:47:11 -07:00
|
|
|
// Maintain parenthesis if the parent expr is of lower precedence
|
|
|
|
|
// This is for clarity, and clippy will not warn on these being unnecessary
|
|
|
|
|
let _ = 2i32 + (x * y);
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
|
|
|
|
|
fix: `identity_op` suggestions use correct parenthesis
The `identity_op` lint was suggesting code fixes that resulted
in incorrect or broken code, due to missing parenthesis in the fix
that changed the semantics of the code.
For a binary expression, `left op right`, if the `left` was redundant,
it would check if the right side needed parenthesis, but if the `right`
was redundant, it would just assume that the left side did not need
parenthesis.
This can result in either rustfix generating broken code and failing,
or code that has different behavior than before the fix.
e.g. `-(x + y + 0)` would turn into `-x + y`, changing the behavior,
and `1u64 + (x + y + 0i32) as u64` where `x: i32` and `y: i32` would
turn into `1u64 + x + y as u64`, creating broken code where `x` cannot
be added to the other values, as it was never cast to `u64`.
This commit fixes both of these cases by always checking the
non-redundant child of a binary expression for needed parenthesis, and
makes it so if we need parenthesis, but they already exist, we don't add
any redundant ones.
Fixes #13470
2024-11-02 19:47:11 -07:00
|
|
|
let x = 1i16;
|
|
|
|
|
let y = 1i16;
|
2024-11-07 20:45:15 -08:00
|
|
|
let _: u64 = 1u64 + ((x as i32 + y as i32) as u64);
|
2025-02-11 17:57:08 +01:00
|
|
|
//~^ identity_op
|
fix: `identity_op` suggestions use correct parenthesis
The `identity_op` lint was suggesting code fixes that resulted
in incorrect or broken code, due to missing parenthesis in the fix
that changed the semantics of the code.
For a binary expression, `left op right`, if the `left` was redundant,
it would check if the right side needed parenthesis, but if the `right`
was redundant, it would just assume that the left side did not need
parenthesis.
This can result in either rustfix generating broken code and failing,
or code that has different behavior than before the fix.
e.g. `-(x + y + 0)` would turn into `-x + y`, changing the behavior,
and `1u64 + (x + y + 0i32) as u64` where `x: i32` and `y: i32` would
turn into `1u64 + x + y as u64`, creating broken code where `x` cannot
be added to the other values, as it was never cast to `u64`.
This commit fixes both of these cases by always checking the
non-redundant child of a binary expression for needed parenthesis, and
makes it so if we need parenthesis, but they already exist, we don't add
any redundant ones.
Fixes #13470
2024-11-02 19:47:11 -07:00
|
|
|
}
|