Macro `literal` fragment specifiers should forward to exact tokens

[tgross35]

Motivating example (playground link):

macro_rules! foo {
    ($a:literal) => {
        foo!(@inner $a);
    };
    (@inner true) => {
        println!("true");
    };
    (@inner false) => {
        println!("false");
    };
}

fn main() {
    foo!(true);
    foo!(false);
}

The above fails to compile because literal does not forward to exact matches, but it doesn't seem like there is any reason it shouldn't. ident or tt can be used, but loosening restrictions can cause other problems.

This probably couldn't be changed without an edition depending on fallout, but we can probably make sure this works with macros 2.0.

The reference makes a comment about forwarding here: https://doc.rust-lang.org/nightly/reference/macros-by-example.html#forwarding-a-matched-fragment

[tgross35]

@rustbot label +A-macros +WG-macros +A-maybe-future-edition +T-lang -needs-triage +A-macros-2.0

[tgross35]

@rustbot label +A-macros-2.0

[petrochenkov]

This is a consequence of - NUM being supported by literal.
literal may contain multiple tokens, so it's wrapped into a delimited group to preserve parsing priorities, similarly to expr, ty and others.
Only tt and ident always represent single tokens and therefore not wrapped.

Some PR with backround discussion - #92472.
Relevant part of the reference - https://doc.rust-lang.org/reference/procedural-macros.html#declarative-macro-tokens-and-procedural-macro-tokens.

Note that the reference deliberately says

Such token streams may be wrapped into delimited groups (Group) with implicit delimiters (Delimiter::None) when it's necessary for preserving parsing priorities.

to accommodate for potential future changes (e.g. omitting grouping for single-token streams).
Whether it can be done backward compatibly in practice is a separate question.

[safinaskar]

@rustbot label +A-macros-2.0