Add FCW to disallow $crate in macro matcher

[nik-rev]

This PR adds a new warn-by-default future incompatibility lint that lints on usage of $crate inside of a macro matcher.

#![deny(dollar_crate_in_matcher)]

macro_rules! x {
    ($crate) => {};
    //~^ ERROR usage of `$crate` in matcher [dollar_crate_in_matcher]
    //~| WARNING this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
}

Tracking Issue: #155123

Reason:

$crate even in macro patterns is getting glued into a single identifier token. Thus, in the macro pattern, it can only be fulfilled by another glued $crate token, which is only possible do in the expansion of a macro.

I think it is better to forbid this usage, as it is strongly inconsistent with the behavior of other keywords in macro binders (they work like any other identifier and are currently not reserved in this position)

Example:

This shows the strange property of $crate in a matcher: the call! macro is defined inside lib.rs, so the $crate token belongs to lib.rs. Yet, despite that, it still matches against the $crate token produced inside of main.rs.

// lib.rs
#[macro_export]
macro_rules! lib_macro {
    ($crate) => {};
}

#[macro_export]
macro_rules! call {
    ($m:path) => {
        $m!($crate);
    };
}

// main.rs
use lib::*;

macro_rules! main_macro {
    ($crate) => {};
}

call!(lib_macro);
call!(main_macro);

fn main() {}

Expected behavior:

• $crate: without a fragment specifier, error indicating that a fragment specifier is missing
• $crate:tt: with a fragment specifier, error indicating that $crate is a reserved identifier that cannot be used as the name of a metavariable.

Explanation and example is from #99037

History:

• Original PR tried to make it an error: Forbid $crate in macro patterns #99447
• From crater, we found 2 breakages from this, notably in ndarray - so it needed to be updated to a future-compatibility lint. Especially now, since 4 years have passed.
• This PR picks up the work by @CAD97 and turns the lint into a future incompatibility lint

Previous PR: #99447, which received no response from the author, so I'm picking it up

Issues:

• $crate in a macro pattern behaves oddly #99037
• $crate is treated as a normal identifier in a macro_rules matcher #147028

CC @CAD97

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 69 candidates
• Random selection from 12 candidates

[nik-rev]

@rustbot label +I-lang-nominated

[fmease]

The list before the => is the matcher, not the transcriber. The $crate in macro_rules! x { ($crate) => {}; } is in the matcher. What's to the right of => is the transcriber.

[nik-rev]

The list before the => is the matcher, not the transcriber. The $crate in macro_rules! x { ($crate) => {}; } is in the matcher. What's to the right of => is the transcriber.

ah, thanks! fixed.

[theemathas]

Does this also fix #147028 ?

[nik-rev]

Does this also fix #147028 ?

I updated this PR to include the test cases from that issue and made sure they also trigger this new lint.

Now, is it right to say that this PR "closes" the issue, considering that the behavior is still the same, albeit linted now?