On Thu, Jan 22, 2026 at 8:46 PM Danilo Krummrich <[email protected]> wrote:
>
> If I run 1.85.0, I *instead* see the following ones from clippy:
>
>   CLIPPY [M] drivers/gpu/drm/tyr/tyr.o
> warning: operator precedence can trip the unwary
>   --> drivers/gpu/drm/tyr/gpu.rs:51:13
>    |
> 51 |             shader_present | 
> u64::from(regs::GPU_SHADER_PRESENT_HI.read(dev, iomem)?) << 32;
>    |             
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  help: consider parenthesizing your expression: `shader_present | 
> (u64::from(regs::GPU_SHADER_PRESENT_HI.read(dev, iomem)?) << 32)`
>    |
>    = help: for further information visit 
> https://rust-lang.github.io/rust-clippy/master/index.html#precedence
>    = note: `-W clippy::precedence` implied by `-W clippy::all`
>    = help: to override `-W clippy::all` add `#[allow(clippy::precedence)]`

I took a look at this --  Rust 1.85.0 extended the `precedence` lint
to catch these, and then because it was too much, they split part of
it into a new one called `precedence_bits` which is not enabled by
default, which landed in Rust 1.86.0 (and is not in Rust 1.85.1,
sadly).

    https://github.com/rust-lang/rust-clippy/pull/13743
    https://github.com/rust-lang/rust-clippy/issues/14097
    https://github.com/rust-lang/rust-clippy/pull/14115

I see others in the kernel have written similar expressions with
parenthesis, e.g. for Rust in `ioctl.rs`, and I see a ton of those in
C files too.

Personally, I don't mind seeing the parenthesis, but I know others may
feel like it is obvious.

Now, seeing quite a bunch of parenthesis for this in C files, from
kernel devs and crypto stuff and all over drivers and so on and so
forth, means others definitely do not find it obvious or prefer to be
explicit for extra clarity.

So we can just clean this one up and later enable `precedence_bits`
for newer versions. Or if we decided it is too much, then I guess I
could allow `precedence` on Rust 1.85.0 only.

Cc'ing others in case they want to give their opinion.

Cheers,
Miguel

Reply via email to