Created attachment 415510 [details]
Patch

Created attachment 415511 [details]
Patch

Comment on attachment 415511 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=415511&action=review

Great job on this very neat change! r=me with a question.

> Source/JavaScriptCore/parser/ParserTokens.h:197
> +    INVALID_TEMPLATE_LITERAL_ERRORTOK = 15 | CanBeErrorTokenFlag,

While introducing CanBeErrorTokenFlag for ESCAPED_KEYWORD makes perfect sense, perhaps we should leave more strict ErrorTokenFlag for other types that are definitely syntax errors?

Comment on attachment 415511 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=415511&action=review

Thanks!!

>> Source/JavaScriptCore/parser/ParserTokens.h:197
>> +    INVALID_TEMPLATE_LITERAL_ERRORTOK = 15 | CanBeErrorTokenFlag,
> 
> While introducing CanBeErrorTokenFlag for ESCAPED_KEYWORD makes perfect sense, perhaps we should leave more strict ErrorTokenFlag for other types that are definitely syntax errors?

I think that every token can cause an error. For example, if keyword appears in `var keyword` place, it is an error.
So, the thing we would like to know is that, whether the produced token can have a special message for parser errors, and this is CanBeErrorTokenFlag which indicates that this token can be an special error token.
I think current form is OK because of two reasons. One is that, this makes CanBeErrorTokenFlag meaning more general, and another reason is that adding another flag (e.g. DefinitelyErrorTokenFlag) consumes token bit, which we would like to keep :)

Will update stress/reserved-word-with-escape.js

Committed r270481: <https://trac.webkit.org/changeset/270481>

<rdar://problem/72017752>

*** Bug 200638 has been marked as a duplicate of this bug. ***