macros sometimes allow expr followed by ident

[durka]

You can use a repetition to get around the future proofer.

macro_rules! bad {
    ($e:expr $i:ident) => {} //~ERROR
}

macro_rules! sneaky {
    ($($i:ident $e:expr)*) => {} // no error
}

fn main() {
    sneaky!(a b c d);
}

I feel that both of these should be accepted, or neither. BTW, I am using the equivalent of sneaky! in brainmunch (found this while preparing my RustFest talk).

Fixing this by disallowing both macros would require cratering.

cc @jseyfried @LeoTestard

[aturon]

cc @pnkfelix

[nikomatsakis]

The danger here is that contextual keywords become impossible. In particular, consider if we added await f as an expression, which would work with bad! today but fail tomorrow.

[joshtriplett]

One possibility would be to leave this alone and fix it in macros 2.0. The other would be a crater run and evaluation for a fix.

[nikomatsakis]

Some possible routes:

• I don't think we should accept bad!, for the reasons given above.
• We could leave this as is -- we have said in the past that when you break the forwards compatibility rules "in spirit" you may get broken.
• Or, better really, we would do a fix and try to do a crater run.

[nikomatsakis]

triage: P-medium

[nikomatsakis]

I feel like we should at least try the fix -- though it may be hard to ascertain the impact entirely.

[durka]

@nikomatsakis do you have any idea how to fix it?

[estebank]

I'm afraid fixing this is going to be problematic, because even we are using this "feature" in rustc. I'll post a PR with the fix (including changing our mis-uses), but will expect there to be breakage. If that is the case after a crater run, should we still include the fix as a warning?