-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Point at type ascription before macro invocation on expansion parse error #62816
Conversation
The only relevant change is the last commit, which adds diagnostic information to |
f840e9b
to
aaaa043
Compare
I need to think whether a less hacky solution exists, I wouldn't want to merge this as is. |
Given the way this works it seems to me like the only available option is to collect the state of the parser at the invocation place. I understand the hesitance of merging the PR as is, but I think it is as good a starting point as we're gonna find without a larger refactor. |
Hey! This is a ping from triage, we would like to know if you @petrochenkov could give us a few minutes to share your thoughts on it. |
aaaa043
to
c82e1f2
Compare
So, the general idea is to create a parser snapshot for every macro invocation, so when the macro is expanded we can parse its output using a parser from that snapshot rather than a fresh parser. Except that the only part of the parser this PR snapshots is the Since we create a fresh parser when expanding any macro anyway (which is not an entirely cheap operation), I wonder, how much more expensive it would be to clone the existing one instead. |
@bors r+ |
📌 Commit c82e1f2 has been approved by |
Point at type ascription before macro invocation on expansion parse error Fix #47666. Follow up to #62791. r? @petrochenkov
☀️ Test successful - checks-azure |
Fix #47666. Follow up to #62791.
r? @petrochenkov