disallowed_macros false negatives

[ojeda]

Summary

disallowed_macros has several false negatives. See reproducer.

Lint Name

disallowed_macros

Reproducer

With clippy.toml:

disallowed-macros = [ "x::m" ]

And a command line like:

clippy-driver --edition=2021 -Dclippy::disallowed_macros x.rs

This works (similar to an existing test in Clippy):

macro_rules! m (
    ($t:tt) => (1)
);

fn main() {
    let _ = m!(42);
}

However, this does not:

macro_rules! m (
    ($t:tt) => ($t)
);

fn main() {
    let _ = m!(42);
}

Nor:

macro_rules! m (
    ($t:tt) => ($t + $t)
);

fn main() {
    let _ = m!(42);
}

In addition, empty expansions also do not work -- this may be due to the lint not having a pre-expansion part, but still, it would be nice to handle:

macro_rules! m (
    ($t:tt) => ()
);

fn main() {
    m!(42);
}

Version

rustc 1.72.0 (5680fa18f 2023-08-23)
rustc 1.74.0-nightly (84a9f4c6e 2023-08-29)

[Alexendoo]

Opened #11439 for ($t:tt) => ($t + $t)

($t:tt) => ($t) doesn't get detected because it doesn't produce any of its own tokens, from the HIR's perspective m!(42) is the same as 42. A pre expansion pass would be able to see an invocation of it as long it's not part of another macro expansion, but it's a late lint because we need to resolve the macro paths to definitions

($t:tt) => () does produce an empty item in the AST, but those are not preserved in the HIR so we don't pick it up

[ojeda]

As an update, we started using allow-invalid because Clippy has not been finding our custom dbg! macro.

[Alexendoo]

That is likely #14733, it's scheduled for a backport

Are you still hitting other FNs with it?