Skip to content

Conversation

@adams85
Copy link
Contributor

@adams85 adams85 commented Jul 7, 2025

In the double lookahead to determine whether it's an await using declaration, the check for the using keyword 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 readWord1 function of the tokenizer.)

BTW, it seems like there are similar issues here:

@adams85 adams85 force-pushed the fix-double-lookahead branch from 85961d4 to b45f21e Compare July 7, 2025 18:55
Copy link
Contributor

@baseballyama baseballyama left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@marijnh marijnh merged commit d3f71a6 into acornjs:master Jul 8, 2025
2 checks passed
@marijnh
Copy link
Member

marijnh commented Jul 8, 2025

Thanks for fixing that!

@adams85
Copy link
Contributor Author

adams85 commented Jul 8, 2025

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?

@marijnh
Copy link
Member

marijnh commented Jul 8, 2025

Either works. I don't have time to look into them today but I could also have a look later this week.

@marijnh
Copy link
Member

marijnh commented Jul 9, 2025

Attached patch adjusts isAsyncFunction to handle a backslash directly after function. I wasn't able to find an actual input on which that changed the parser's behavior, but it does make the function return the right thing, which counts for something.

I don't think there's an issue in isLet. If there's a backslash directly after let, that will have been tokenized as part of an identifier token, and isContextual("let") will already return false.

@adams85
Copy link
Contributor Author

adams85 commented Jul 9, 2025

Attached patch adjusts isAsyncFunction to handle a backslash directly after function. I wasn't able to find an actual input on which that changed the parser's behavior, but it does make the function return the right thing, which counts for something.

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. (My original fix was incorrect too.) EDIT: see the description of the linked PR

I submitted another PR, which hopefully sorts this out once and for all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants