Open traviscross opened 2 weeks ago
I think that this FCW could be implemented, but also I think it's a bit of a shame we can't detect this at the macro definition site like we can for a follow-set error.
That would require having to like... construct like NDFAs for each matcher arm and compare them to detect when $tt:tt
conflicts in the way I mentioned above, so I don't think it's possible or at least remotely implementable.
In the meeting today, we didn't quite have time to discuss this, but @nikomatsakis noted:
I don't think this proposal is sufficient but I am interested in pursuing a real fix to this for a future edition.
Example:
macro_rules! test { (if $x:ty { }) => {}; (if $x:expr { }) => {}; }
This basically says to pick one arm if something is a type, another if it's an expression. Extending the type grammar to cover new cases could change which arm you go down to.
I think the most general fix is to say: when you would start parsing a fragment, first skip ahead to find the extent of it (i.e., until you see an entry from the follow-set). Then parse it as the fragment. If the parsing fails or there are unconsumed tokens, report a hard error.
I suspect it would break a lot in practice and we would need an opt-in.
Over in:
@compiler-errors describes this general problem:
And @Noratrieb proposes a general solution:
This issue is to track the proposal for this FCW.
cc @Noratrieb @compiler-errors @eholk @rust-lang/lang