Fix cross-edition fragment specifier span behavior

[traviscross]

In the lang call on 2024-09-04, we agreed that the span of the token used to fill in the fragment specifier should be used for deciding the behavior.

That is, if we have code like this in a Rust 2021 crate:

#[macro_export]
macro_rules! make_matcher {
    ($name:ident, $fragment_type:ident, $d:tt) => {
        #[macro_export]
        macro_rules! $name {
            ($d _:$fragment_type) => { true };
            (const { 0 }) => { false };
        }
    };
}
make_matcher!(is_expr_from_2021, expr, $);

And code like this in a Rust 2024 crate:

make_matcher!(is_expr_from_2024, expr, $);

We would expect that is_expr_from_2024 would exhibit the Rust 2024 behavior.

We'd also like to fix this for pat, pending of course a crater run.

cc #129755

cc @eholk @vincenzopalazzo @compiler-errors

Tracking:

• Tracking Issue for updating expr macro fragment specifier for Rust 2024 #123742

[compiler-errors]

I mentioned in the linked PR, but I don't see it here, so I'll repeat myself for clarity:

#129755 (comment)

I actually don't think this is possible to implement, due to existing bugs (#85708). Namely, we have trouble determining the span of a nonterminal token (which is used to compute the edition) when there's extern crates involved.

I would prefer if we decouple fixing this bug (both expr_2021 and pat) given that this is essentially a theoretical regression, and go ahead with this behavior.

That is, we go ahead with the existing behavior for now, and not further block the stabilization of expr_2021 on this issue. I do agree with the desired behavior from T-lang though.