-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Point at type ascription before macro invocation on expansion parse error #62816
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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