Closed Bug 933809 Opened 11 years ago Closed 9 years ago

The SyntaxParser does not correctly report errors for (parenthesized) nodes


(Core :: JavaScript Engine, defect)

Not set





(Reporter: terrence, Unassigned)



The test case for bug 932530 triggers this:

function f(x) {
    "use strict";
    return delete (b);
const y = 1 + Math.pow(2, -52);
var diff = function (a, b) {
    f[0] = a;
    f[1] = b;
diff(1, y);

In a strict function, |delete <name>| is disallowed and should raise SyntaxError at parse time. Thus, function |f| in the above test should raise a SyntaxError, and indeed does when run with baseline-eager and TI enabled. However, in the default case, where only the SyntaxParser is run on |f|, this error is not raised and the script completes successfully.

The problem is that the syntax parser calls setInParens on |(b)|, which treats |(b)| as GenericNode instead of NameNode. Later, analysis of TOK_DELETE incorrectly sees |isName| as false. The |setInParens| function has the comment "String literals enclosed by parentheses are ignored during strict mode parsing"; this appears to be less true for errors.
See Also: → 932530
I mentioned on IRC that I wasn't even sure the specs said this should be a strict mode error.  It turns out in ES5 the relevant language is that it's an error if the delete operand is a "direct reference to a variable, function argument, or function name".  There's no elaboration of what a "direct reference" is, anywhere that I can find.  (Compare to
Bleh, hit Enter too early.  Meant to continue:

...the "direct call to eval" phrase used to describe when an eval is direct versus indirect, which elaborates the exact cases where an eval is direct versus not.)

So, I think this testcase's correctness needs some investigation to determine whether it should be an early syntax error, or no error at all.  ES6 may well specify this more clearly; we should check there first.  If that's not clear, we'll have to ask TC39 what should happen.  Possibly consistency with the eval case, specifically with (eval)("this is direct"), argues for the parentheses being ignored, but I could be mistaken, having only thought about it for a few minutes.
Assignee: general → nobody
No longer reproducible - Resolving as WFM.

(Maybe fixed in ?)
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.