Macro parsing ambiguity rules overly strict about repetition of the same token

[joshtriplett]

RFC 550 (https://github.com/rust-lang/rfcs/blob/master/text/0550-macro-future-proofing.md) restricted macro syntax to future-proof against changes to Rust syntax. However, this breaks a case that can be handled unambiguously, namely repetition of the same token that splits off the rightmost rather than leftmost item:

macro_rules! foo {
    () => ( ... );
    ( $($init:ident)* $last:ident ) => ( ... foo! { $($init)* } );
}

This produces the following error:
error: local ambiguity: multiple parsing options: built-in NTs ident ('init') or ident ('last') or 0 other options.

This kind of syntax is useful for recursively parsing a list and repeatedly dropping the last item (rather than repeatedly dropping the first).

Rust should be able to handle this case unambiguously, as long as the repeated token type can't match the closing delimiter of the macro, which ident clearly never will.

[joshtriplett]

Note that this applies even if the macro requires a delimiter between the tokens:

macro_rules! foo {
    () => ( ... );
    ( $($init:ident,)* $last:ident ) => ( ... foo! { $($init),* } );
}

[nikomatsakis]

cc @pnkfelix

But that said, I don't really think this has much to do with RFC 550. I think this is a problem with the macro parser's greedy parsing strategy (combined with its inability to ever fallback).

[pnkfelix]

Yes local ambiguity messages arise during expansion, not the ahead of time future proofing check

[tinco]

I've got exactly this same problem, trying to extract the last element from a list doesn't work because of this issue.

[pnkfelix]

cc @LeoTestard

[Mark-Simulacrum]

This compiles successfully today. Marking as E-needstest.

[fflorent]

@Mark-Simulacrum I encounter the same issue. AFAICT, it doesn't compile (or I may miss something) :
https://is.gd/rj5hNJ

Florent

[Mark-Simulacrum]

Hm, yeah, you're right. Not sure what I tested. Unmarking E-needstest.

[kennytm]

Same as #42838? You certainly need to back-track one token from init in order to match the last.

[Mark-Simulacrum]

Yeah, this is unlikely to get solved differently from #42838 so closing in favor of that.