-
Bug
-
Resolution: Fixed
-
P3
-
9
-
None
-
b28
-
generic
-
generic
Currently in Nashorn we allow reserved words identifiers that contain unicode escape sequences as they not recognized as reserved words because TokenLookup.lookupKeyword (called from Lexer.scanIdentifierOrKeyword) is not aware of unicode escapes.
Thus, reserved word with unicode escapes are parsed as identifiers. These identifiers are filtered out later by a second call to TokenLookup.lookupKeyword from Parser.verifyIdent, but only when running in ES6 mode.
A few notes to the current implementation:
- We should recognize reserved words with unicode escapes even in ES5 mode. Although above sentence was added only in ES6, ES5 is clear that a unicode escape is equivalent to the code point it represents. I think this is more a clarification rather than a change in ES6.
- The dual calling of TokenLookup.lookupKeyword is probably rather inefficient.
Thus, reserved word with unicode escapes are parsed as identifiers. These identifiers are filtered out later by a second call to TokenLookup.lookupKeyword from Parser.verifyIdent, but only when running in ES6 mode.
A few notes to the current implementation:
- We should recognize reserved words with unicode escapes even in ES5 mode. Although above sentence was added only in ES6, ES5 is clear that a unicode escape is equivalent to the code point it represents. I think this is more a clarification rather than a change in ES6.
- The dual calling of TokenLookup.lookupKeyword is probably rather inefficient.