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`
}
```
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`
}
```
Fixes#11846.
This PR has three commits:
- The first commit adds an `initializer-suggestions` configuration to
control suggestion applicability when initializers are present. The
following are the options:
- "none": do not suggest
- "maybe-incorrect": suggest, but do not apply suggestions with `--fix`
- "machine-applicable": suggest and apply suggestions with `--fix`
- The second commit fixes suggestions to handle field attributes
(problem [noticed by
@samueltardieu](https://github.com/rust-lang/rust-clippy/pull/13737#discussion_r1859261645)).
- The third commit adds `initializer-suggestions = "machine-applicable"`
to Clippy's `clippy.toml` and applies the suggestions. (Nothing seems to
break.)
---
changelog: make `inconsistent_struct_constructor` "all fields are
shorthand" requirement configurable
the behavior of the type system not only depends on the current
assumptions, but also the currentnphase of the compiler. This is
mostly necessary as we need to decide whether and how to reveal
opaque types. We track this via the `TypingMode`.
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 rustfix generating broken code and failing, or
generating 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 an error where `x` cannot be added
to the other values, as it was never cast to `u64`.
This commit fixes both of these problems by always checking the
non-redundant child of a binary expression for needed parenthesis.
fixes#13470
changelog: [`identity_op`]: Fix suggested code that is broken or has
changed behavior
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
This removes the ICE codepaths for `f16` and `f128` in Clippy.
`rustc_apfloat` is used as a dependency for the parsing of these types,
since their `FromStr` implementation will not be available in the
standard library for a while.
