OR_PATTERNS_BACK_COMPAT lint ignores crate boundaries

[digama0]

Code in main crate:

#![warn(or_patterns_back_compat)]
#[macro_use] extern crate bar;
fn main() { foo!(_|); }

Crate bar:

#[macro_export] macro_rules! foo { ($x:pat|) => {} }

Result:

$ cargo check
    Checking bar v0.1.0 (/bar)
    Checking test v0.1.0 (/test)
warning: the meaning of the `pat` fragment specifier is changing in Rust 2021, which may affect this macro
 --> /bar/src/lib.rs:1:37
  |
1 | #[macro_export] macro_rules! foo { ($x:pat|) => {} }
  |                                     ^^^^^^ help: use pat_param to preserve semantics: `$x:pat_param`
  |
note: the lint level is defined here
 --> src/main.rs:1:9
  |
1 | #![warn(or_patterns_back_compat)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2021 edition!
  = note: for more information, see issue #84869 <https://github.com/rust-lang/rust/issues/84869>

warning: 1 warning emitted

    Finished dev [unoptimized + debuginfo] target(s) in 0.19s

This lint should be suppressed, because it originates in another crate.

• rustc --version: rustc 1.55.0-nightly (6a758ea7e 2021-06-22)

[inquisitivecrystal]

I'm going to take a look and see if I can figure this out.

@rustbot label +A-macros +C-bug
@rustbot claim

[m-ou-se]

This is probably something to be fixed as part of #86330. @rylev said he'll look into it.

[m-ou-se]

Looks like this is unrelated to the future incompatibility lint mechanism, but a bug with the or pattern lint specifically. It seems to trigger not only on the macro_rules definition, but also when such a definition is used.

[m-ou-se]

That seems somewhat related to #85709. Though that PR doesn't fix it.

[rylev]

@inquisitivecrystal I'm going to take a look into this as part of #86330. Let me know if you've already started looking into this.

[m-ou-se]

This is fixed by #86574

[inquisitivecrystal]

I thought the problem was that the lint was being passed the wrong NodeId. That would make it pretty separate from anything else, though it might make sense to deal with it in #86574, which is touching a lot of the same code anyway. I was pretty close to a draft implementation last night, though I hadn't actually reached the point of testing that it works, so I could well have been totally wrong about where the problem was. If someone else is rewriting the same code, it doesn't really make sense for me to finish my implementation.