-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Strange order dependency for macro that matches _ and ident #39964
Comments
Annoyingly, the macro expander doesn't attempt to handle this kind of ambiguity at all. It won't back out of |
I don't think this is really a direct issue since this basically resolves to the macro expander being unable to handle ambiguity between macro arms. As such, I'm going to close. |
Fixes rust-lang#24189. Fixes rust-lang#26444. Fixes rust-lang#27832. Fixes rust-lang#34030. Fixes rust-lang#35650. Fixes rust-lang#39964. Fixes the 4th comment in rust-lang#40569. Fixes the issue blocking rust-lang#40984.
…seyfried Only match a fragment specifier the if it starts with certain tokens. When trying to match a fragment specifier, we first predict whether the current token can be matched at all. If it cannot be matched, don't bother to push the Earley item to `bb_eis`. This can fix a lot of issues which otherwise requires full backtracking (#42838). In this PR the prediction treatment is not done for `:item`, `:stmt` and `:tt`, but it could be expanded in the future. Fixes #24189. Fixes #26444. Fixes #27832. Fixes #34030. Fixes #35650. Fixes #39964. Fixes the 4th comment in #40569. Fixes the issue blocking #40984.
A
macro_rules!
macro with two cases that match_
andident
might not match_
depending on the order of the cases. This works:But this doesn't:
...giving the error message:
Why would it expect an
ident
there? If_
isn't anident
, shouldn't it just move on to the second macro case and match that?The text was updated successfully, but these errors were encountered: