Macros do not suppress double_parens warnings anymore

[bonzini]

Summary

Clippy does not suppress lints anymore within a macro.

Reproducer

Reduced testcase:

#[repr(transparent)]
#[derive(Clone, Copy, PartialEq, Eq)]
pub struct InterruptMask(u32);
macro_rules! foo {
    ($a:expr, $b:expr, $c:expr, $d:expr) => {
        InterruptMask(((($a.union($b).union($c).union($d))).into_bits()) as u32)
    }
}

impl InterruptMask {
    pub const OE: InterruptMask = InterruptMask(1 << 10);
    pub const BE: InterruptMask = InterruptMask(1 << 9);
    pub const PE: InterruptMask = InterruptMask(1 << 8);
    pub const FE: InterruptMask = InterruptMask(1 << 7);
    pub const E: InterruptMask = foo!(Self::OE, Self::BE, Self::PE, Self::FE);
    pub const fn into_bits(self) -> u32 {
        self.0
    }
    #[must_use]
    pub const fn union(self, rhs: Self) -> Self {
        InterruptMask(self.0 | rhs.0)
    }
}

Expected result:

$ clippy-driver +nightly-2025-10-07 --crate-type rlib -D warnings --edition=2021 -C opt-level=2 -g  -D warnings f.rs
<no output>

Actual result:

$ clippy-driver +nightly --crate-type rlib -D warnings --edition=2021 -C opt-level=2 -g  -D warnings f.rs
error: unnecessary parentheses
  --> f.rs:6:24
   |
 6 |         InterruptMask(((($a.union($b).union($c).union($d))).into_bits()) as u32)
   |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove them: `($a.union($b).union($c).union($d))`
...
15 |     pub const E: InterruptMask = foo!(Self::OE, Self::BE, Self::PE, Self::FE);
   |                                  -------------------------------------------- in this macro invocation
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#double_parens
   = note: `-D clippy::double-parens` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::double_parens)]`
   = note: this error originates in the macro `foo` (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 1 previous error

Version

rustc 1.92.0-nightly (b6f0945e4 2025-10-08)
binary: rustc
commit-hash: b6f0945e4681bc4d2faa7c22c5f61dc36abf7dd2
commit-date: 2025-10-08
host: x86_64-unknown-linux-gnu
release: 1.92.0-nightly
LLVM version: 21.1.2

Additional Labels

No response

[bonzini]

This is the actual CI run: https://gitlab.com/bonzini/qemu/-/jobs/11666011883. The expansion in that case is from a procedural macro.

It also breaks clippy::enum_variant_names, and also from a procedural macro. The enum_variant_names is real (though in that specific case there's a reason for the repetition) and shows an improvement in clippy! 😄

[Jarcho]

Lints are not, in general, suppressed inside macros. Many lints won't lint in macros because it's hard to determine if it's only some invocations should trigger the lint or all invocations will trigger the lint. For double_parens linting there is intentional.

enum_variant_names is still an FP. It's being caused by an external macro which should be suppressing basically all lints.

[bonzini]

Could the double_parens lint at least be hidden from procedural macros? In the real testcase, I'm generating an expression by parsing a DSL, and producing the extra parentheses makes the macro much easier.

I could work around the issue; for example I could use a macro to make the parentheses invisible to the compiler, while keeping the correct priorities for the overall expr. But that would be quite ugly.

[Jarcho]

If it's linting in procedural macro generated code that's a bug (technically the macro is using the wrong context for the spans, but we can mostly detect this). If it's linting when the macro is expanding something like (($a + $b) $(* $c)?) then that would also be a bug.

[bonzini]

Ok, then here's the testcase using a procedural macro:

• Macro: bits.rs
• Source: bug.rs

Bad:

$ rustc +nightly --crate-type=proc-macro bits.rs  --edition=2021 --crate-name bits
$ clippy-driver +nightly --extern bits=libbits.so bug.rs --edition=2021 
warning: unnecessary parentheses

Good:

$ rustc +nightly-2025-10-07 --crate-type=proc-macro bits.rs  --edition=2021 --crate-name bits
$ clippy-driver +nightly-2025-10-07 --extern bits=libbits.so bug.rs --edition=2021

[sendittothenewts]

The trouble with this is that the warnings are going to the wrong audience: the users of the macro rather than the author. When you use a macro from a 3rd party crate, you get warnings you can do little about. Even suppressing the lint is awkward as the #[allow] attribute can't be attached to the macro call.