-
Notifications
You must be signed in to change notification settings - Fork 986
Fix await using double lookahead edge case #1382
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
Conversation
85961d4 to
b45f21e
Compare
baseballyama
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
|
Thanks for fixing that! |
|
My pleasure. However, how about the other similar cases of lookaheads I mentioned above, in the PR description? Shall I submit another PR and shall we discuss those there? |
|
Either works. I don't have time to look into them today but I could also have a look later this week. |
|
Attached patch adjusts I don't think there's an issue in |
Thank you. This will report the error at the correct position BTW. However, it's still not completely correct as it doesn't account for astral identifier characters. I submitted another PR, which hopefully sorts this out once and for all. |
In the double lookahead to determine whether it's an await using declaration, the check for the
usingkeyword is not correct. Adding a Unicode escaped identifier character fools the parser logic:async () => { await using\\u0061 b = c }This incorrectly parses without an error.
I made an attempt at fixing the issue. (This way we should be consistent with the
readWord1function of the tokenizer.)BTW, it seems like there are similar issues here:
acorn/acorn/src/statement.js
Line 73 in ad66d00
acorn/acorn/src/statement.js
Line 45 in ad66d00