fix(es/parser): reject unicode escapes in RegExp flags - #12093
fix(es/parser): reject unicode escapes in RegExp flags#12093Felix-Ayush (Ayush7614) wants to merge 3 commits into
Conversation
🦋 Changeset detectedLatest commit: ef4489e The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
ECMA-262 makes a Syntax Error when RegExp flags contain a Unicode escape sequence. The lexer already detected escapes via read_word_as_str_with but discarded has_escape; honor that flag and also accept flags that begin with a backslash escape.
684abb4 to
c8044ac
Compare
Merging this PR will not alter performance
Comparing Footnotes
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c8044ac6bd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "Codex (@codex) review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "Codex (@codex) address that feedback".
| Some(c) if c.is_ident_start() => self | ||
| .read_word_as_str_with() | ||
| .map(|(s, _)| Some(self.atom(s))), | ||
| Some(c) if c == b'\\' || c.is_ident_start() => { |
There was a problem hiding this comment.
Keep scanning non-ASCII regexp flags
When the first flag is non-ASCII, self.cur() is only the first UTF-8 byte, so c.is_ident_start() is false and this branch is skipped. That leaves inputs such as /a/π\u0067 tokenized as /a/ followed by an identifier, so the new unicode-escape-in-flags diagnostic (and the existing unknown-flag validation) never runs for these regexp flags. Please use the current character/IdentifierPart-aware path before deciding there are no flags.
Useful? React with 👍 / 👎.
cur() only yields the first UTF-8 byte, so flags starting with a non-ASCII IdentifierPart (e.g. /a/π\u0067) were skipped. Use cur_as_char() and is_ident_part() before deciding there are no flags.
Rejecting unicode escapes in flags consumes the invalid flag sequence, so the secondary "Expected a semicolon" recovery diagnostic is no longer emitted for these test262 fail cases.
Description:
ECMA-262 requires a Syntax Error when IdentifierPart in RegExp flags contains a Unicode escape sequence. SWC's lexer had an explicit TODO for this and discarded the
has_escapeflag fromread_word_as_str_with, so inputs like/a/g\u0069parsed successfully even though engines reject them.This change:
UnicodeEscapeInRegExpFlagswhen flags contain\u/\u{...}escapes\so fully-escaped flags such as/\u0067are scanned and rejected correctlyVerified against Node and with fixtures under
tests/errors/regexp-flags-unicode-escape/**.Related issue (if exists):
N/A (direct PR; no existing tracked issue)