Open Protryon opened 6 years ago
I'm inclined to think that, of the two tests, the one in test262 is incorrect (when it claims there's a syntax error).
In the expression new.\u0074arget
(or new.t\u0061rget
), the lexical parser will recognize the characters after the dot as an IdentifierName
(specifically, InputElementDiv -> CommonToken -> IdentifierName
). As such, 11.6 Names and Keywords applies: "Unicode escape sequences are permitted in an IdentifierName".
The info
of the test262 test quotes 5.1.5 Grammar Notation: "Terminal symbols of the lexical, RegExp, and numeric string grammars [...] are to appear in a script exactly as written." However, this is irrelevant to the test. The production NewTarget : new . target
belongs to the syntactic grammar, and so target
is a terminal symbol of the syntactic grammar, not the lexical.
@jmdyck If that would be true, it would apply to super
, new
and all the other keywords in syntactic grammar, but it doesn't.
11.6 does permit unicode escape sequences, but it doesn't say to decode them in general case, which means new.t\u0061rget
is not NewTarget
and then can be tried to be parsed only as MemberExpression
.
But it's not valid MemberExpression
either because of new
which is valid IdentifierName
but not valid Identifier
-> IdentifierReference
-> PrimaryExpression
, hence a syntax error.
11.6 does permit unicode escape sequences, but it doesn't say to decode them in general case
I think it does. It says "Unicode escape sequences are permitted in an IdentifierName, where they contribute a single Unicode code point to the IdentifierName." It doesn't say that the interpretation of escape sequences occurs only sometimes, and not in some "general case". In fact, the last sentence of the paragraph says that all interpretations of IdentifierName
within the spec include the interpretation of Unicode escape sequences.
Mind you, I think it's clear that TC39 intends this to be a Syntax Error; I just think the spec says pretty much the opposite. So I'll raise a spec bug.
pass/3dbb6e166b14a6c0.js was moved to fail/ in PR #23, so this issue can presumably be closed.
Test file: pass/3dbb6e166b14a6c0.js