Determining if the LHS of an AssignmentExpression is parenthesized

[TimothyGu]

Or, distinguishing between

fn = function () {};

and

(fn) = function () {};

Spec-wise, the first would have a left-hand side of PrimaryExpression : IdentifierReference, while the second would have PrimaryExpression : CoverParenthesizedExpressionAndArrowParameterList. This then leads to the IsIdentifierRef static semantic returning true for the first, and false for the second.

Through IsIdentifierRef, the distinction has real implications during run-time. The first would automatically name the newly created function using SetFunctionName to "fn", while the second would not. Indeed, this is tested in tc39/test262 language/expressions/assignment/fn-name-lhs-cover.js.

However as of now, ESTree does not distinguish between the two variants, making it impossible to write a compliant JavaScript engine with an ESTree AST alone. Is there any guidance one could follow when implementing this?

[TimothyGu]

I should point out that V8 currently implements this wrongly, but ChakraCore and SpiderMonkey both do so correctly.

[mysticatea]

Oh. Indeed, this sounds that ESTree should be updated.

[TimothyGu]

For cowpath-paving information, Acorn provides a preserveParens option that fixes exactly this:

If this option is true, parenthesized expressions are represented by (non-standard) ParenthesizedExpression nodes that have a single expression property containing the expression inside parentheses.

It would be great to be able to standardize that.

[nzakas]

I actually love the Acorn extension because I think it's incredibly useful. However, I believe that this proposal would be a breaking change, and we generally not accepted breaking changes because it would require every tool that currently produces ESTree to change along with it. For instance, ESLint supports a number of ESTree-based parsers and it would be difficult to know if we could rely on a ParenthesizedExpression to be present or not. (Further discussion on breaking changes is in #65.)

You can definitely copy what Acorn does (or just use Acorn) if you want to create an implementation that has this extension, but I'm not sure it can be part of ESTree formally without a lot of coordination and effort.

[RReverser]

I wonder if it would be possible instead to define this as a boolean field in contexts where it matters in runtime (like Identifier in example above). Then it would become a backward-compatible extension.