-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Don't accidentally parse MatchNt #22814
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I guess it used to turn into a |
1.0-beta, P-backcompat-lang. |
Fixes rust-lang#21370. `unused-macro-with-follow-violation.rs` was already handled correctly. That test is just for good measure. :) I have a more involved plan to clean this up, but it ran into difficulties such as rust-lang#22814.
My best plan at the moment is to change the parser so it never parses (There is already some other code that decomposes a |
The main parser won't even parse |
@bstrie is going to look into this. |
Provisionally reclassifying as 1.0. @kmcallister is there a strong reason to put this back on the 1.0 beta milestone? @bstrie is there a status update? |
I'm not sure if this is actually a back-compat hazard on I agree that we can put this off until 1.0-final. |
Triage: Can't reproduce. @kmcallister?
|
…lexcrichton Closes rust-lang#22814
This bit of macro from
libcore
:was apparently parsing as a MatchNt
$name:Hash
, which breaks with my fix to #21370.There's no need to parse MatchNt on a macro RHS, but we don't know we're on a macro RHS when we're parsing a token tree. Probably we should get rid of MatchNt. It's a weird "composite token" and the tokenizer phase is clearly too early to spot it. Rather we can look for the colon and fragment specifier when we parse a LHS TT into matchers.
Nominating 1.0-beta, P-backcompat-lang.
The text was updated successfully, but these errors were encountered: