iter_without_into_iter fires on code generated by macros from other crates

[jyn514]

Summary

iter_without_into_iter fires on external macros.

Lint Name

iter_without_into_iter

Reproducer

I tried this code with bitflags version 2.3.2 (note that later versions may not reproduce the lint):

#![warn(clippy::pedantic)]

bitflags::bitflags! {
    pub struct HttpComponents: u16 {
        const REQUEST_RESPONSE = 1 << 0;
    }
}

I saw this happen:

warning: `iter` method without an `IntoIterator` impl for `&$BitFlags`
  --> src/main.rs:4:1
   |
4  | / bitflags! {
5  | |     ///  Configuration for HTTP metadata fields.
6  | |     #[derive(Copy, Clone)]
7  | |     pub struct HttpComponents: u16 {
...  |
18 | |     }
19 | | }
   | |_^
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#iter_without_into_iter
   = note: this warning originates in the macro `__impl_public_bitflags_iter` which comes from the expansion of the macro `bitflags` (in Nightly builds, run with -Z macro-backtrace for more info)

I expected to see this happen: No warning, because this is not code I can change.

Version

clippy 0.1.75 (82e1608d 2023-12-21)
rustc 1.75.0 (82e1608df 2023-12-21)

Additional Labels

No response

[jyn514]

there's a further issue here that there's nowhere to put the #[allow()] attribute. putting it on the macro invocation does nothing (and warns that it's ignored), putting it on the struct means it's expanded the macro and shows up on the struct itself but not the impl block that defines fn iter.

going to put it at the module level for now - i think this makes a good case for never firing lints in foreign macros tbh, since you can't apply attributes to them.

[jyn514]

i wonder if rustc in general (not just clippy) could - instead of ignoring the attribute - for lints specifically, apply the lint level to all code generated by the macro.

[Xuanwo]

#12039 seems also related to this: Lint that emitted against an external type.

[m-rph]

@rustbot label +T-macros