In macros, `$($x:expr),*` fragments can be used to bypass future-proofing restrictions

[nikomatsakis]

This should not be accepted, but it is:

macro_rules! foo {
    ( $($x:expr),* ... ) => { 1 }
}

fn main() { }

cc @pnkfelix @cmr

[nikomatsakis]

cc @bluss

[nikomatsakis]

Note that

macro_rules! foo {
    ( $x:expr ... ) => { 1 }
}

fn main() { }

is (correctly) prohibited.

[bluss]

It's not just the type expr, I also tested pat.

[DanielKeep]

Nooooooo! You're going to break my macro article again, aren't you? :(

(Note: I realise the following is not a good reason to not fix this problem.)

The problem for me, personally, is that the following doesn't work:

macro_rules! foo {
    ( $($x:expr),* , ... ) => { 1 }
}

fn main() {
// error: local ambiguity: multiple parsing options: built-in NTs expr ('x') or 1 other options.
    let _ = foo!(1, 2, 3, ...);
//                        ^~~
}

It would be nice if MBE preferred literal matches to captures.

[Stebalien]

@DanielKeep Shouldn't that be $($x:expr,)*? Your example won't work anyways for the reason you posted but fixing this bug shouldn't change anything. Anyways, you should be able to do this with a recursive macro:

macro_rules! foo {
    (...) => {{
        ()
    }};
    ($e:expr, $($tok:tt)+) => {{
        ($e, foo!($($tok)+))
    }}
}

fn main() {
    let tpl = foo!(1,2,3,4,...);
    println!("{:?}", tpl);
}

[alexcrichton]

triage: I-nominated

[nikomatsakis]

cc @pnkfelix

[nikomatsakis]

So my feeling is that we should probably fix this, but it'd be good to evaluate the impact. It might be a good place to use a more elongated "breaking change procedure", or at least actively reach out to help people rewrite.

[emberian]

Is this a bug where we need to consider "FOLLOW"? I thought I saw a PR/RFC that added detailed FOLLOW checking but I could be wrong.

[bluss]

Would it be a middle ground to always warn on this, and then "just let it break" if expression syntax ever changes so that it does -- the macro would suddenly match differently.

@DanielKeep and I found out a parsing strategy with $x:tt $($xs:tt)* where you can split on any token you want to and reinterpret the parts on either side. That is like an explicit way to circumvent any syntax restriction, and it's not tied to any changing meaning of expr or similar macro parts.

[nikomatsakis]

triage: P-high

Assigning high priority as, if we are going to fix this, we need to do it soon. If we're just going to warn, urgency is somewhat lower. I'm not yet sure of best overall strategy here. A crater report might be helpful in making the determination.