Macros that emit attributes do not trigger at the correct node in `disallowed_macros`

[BatmanAoD]

Description

I wanted to write a "wrapper" macro around tracing::error, then disallow tracing::error itself, but it seems I can't just put an allow in the "wrapper" macro itself. Here's a sort of "dummy" version of what I'm doing:

macro_rules! my_error {
    ($($args:tt)+) => {
        #[allow(clippy::disallowed_macros)]
        if <some logic> {
            tracing::error!(<some extra fields>, $($args)+);
        } else {
            tracing::error!($($args)+)
        }
    }
}

The allow seems to have absolutely no effect. Is there a way to do this correctly?

Version

rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: aarch64-apple-darwin
release: 1.88.0
LLVM version: 20.1.5

Additional Labels

@rustbot label +C-question

[profetia]

I cannot reproduce this issue. Here is what I did:
main.rs:

  macro_rules! my_error {
      ($($args:tt)+) => {
          #[allow(clippy::disallowed_macros)]
          if todo!() {
              std::eprintln!($($args)+);
          } else {
              std::eprintln!($($args)+);
          }
      }
  }

  pub fn test() {
      my_error!("This is an error message with some extra fields");
  }

clippy.toml

disallowed-macros = ["std::eprintln"]

[BatmanAoD]

I don't know why, but it seems to be specific to tracing::error!. Please try with that.

[Alexendoo]

It will occur when the macro emits an attribute

macro_rules! m {
    () => {
        #[repr(C)]
        struct S {}
    };
}

#[allow(clippy::disallowed_macros)]
fn main() {
    m!();
}

[BatmanAoD]

Interesting; any idea if there's a possible workaround?

[Alexendoo]

The lint emits at the crate root, so you could do

#![allow(clippy::disallowed_macros)]

#[warn(clippy::disallowed_macros)]
mod foo;

which of course is annoying the more items you have in there, but if you only need the lint in one/two specific modules it could work

[zihan0822]

same issue as #14017