Represent implicit 'this' binding by 'super' in AST.

Represent implicit 'this' binding by 'super' in AST.

This makes the implicit initializing assignment to 'this' performed
after a super constructor call explicit in the AST. It removes the
need to handle the special case where a CallExpression behaves like a
AssignmentExpression from various AstVisitor implementations.

R=rossberg@chromium.org

Committed: https://crrev.com/07dc66dcd5d9bc266915d67142425dd92e1373ad
Cr-Commit-Position: refs/heads/master@{#29705}

[Michael Starzinger, 2015-07-16 10:55:28]

mstarzinger@chromium.org changed reviewers:
+ adamk@chromium.org

[Michael Starzinger, 2015-07-16 10:55:29]

Andreas: PTAL.
Adam: FYI.

[rossberg, 2015-07-16 11:50:48]

lgtm

https://codereview.chromium.org/1226123010/diff/20001/src/ast.cc
File src/ast.cc (right):

https://codereview.chromium.org/1226123010/diff/20001/src/ast.cc#newcode62
src/ast.cc:62: bool Expression::IsVariableProxyOrProperty() const {
I have a slight preference for

IsValidReferenceExpressionOrThis() = IsValidReferenceExpression() || IsThis()

but I'd be fine with the current version as well.

[rossberg, 2015-07-16 11:58:17]

Actually, it seems like we have zero test coverage for checking the return value
of super calls. With this CL you probably want to add some.

[Michael Starzinger, 2015-07-16 12:46:19]

https://codereview.chromium.org/1226123010/diff/20001/src/ast.cc
File src/ast.cc (right):

https://codereview.chromium.org/1226123010/diff/20001/src/ast.cc#newcode62
src/ast.cc:62: bool Expression::IsVariableProxyOrProperty() const {
On 2015/07/16 11:50:48, rossberg wrote:
> I have a slight preference for
> 
> IsValidReferenceExpressionOrThis() = IsValidReferenceExpression() || IsThis()
> 
> but I'd be fine with the current version as well.

Done. Your slight preference is my command.

[Michael Starzinger, 2015-07-16 13:28:55]

Ported to all architectures and added test coverage.

[rossberg, 2015-07-16 13:30:59]

lgtm

https://codereview.chromium.org/1226123010/diff/80001/test/mjsunit/harmony/su...
File test/mjsunit/harmony/super.js (right):

https://codereview.chromium.org/1226123010/diff/80001/test/mjsunit/harmony/su...
test/mjsunit/harmony/super.js:1983: derivedCalled++;
Nit: any reason to separate the computation and the assert by this line?
(Similarly two cases below)

[Michael Starzinger, 2015-07-16 13:40:15]

https://codereview.chromium.org/1226123010/diff/80001/test/mjsunit/harmony/su...
File test/mjsunit/harmony/super.js (right):

https://codereview.chromium.org/1226123010/diff/80001/test/mjsunit/harmony/su...
test/mjsunit/harmony/super.js:1983: derivedCalled++;
On 2015/07/16 13:30:58, rossberg wrote:
> Nit: any reason to separate the computation and the assert by this line?
> (Similarly two cases below)

Done. Nope, no reason, I just do these things to spice up my life a little. :)

[Michael Starzinger, 2015-07-16 13:43:57]

The CQ bit was checked by mstarzinger@chromium.org

[Michael Starzinger, 2015-07-16 13:43:58]

The patchset sent to the CQ was uploaded after l-g-t-m from
rossberg@chromium.org
Link to the patchset: https://codereview.chromium.org/1226123010/#ps100001
(title: "Addressed comments.")

[commit-bot: I haz the power, 2015-07-16 13:44:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1226123010/100001

[commit-bot: I haz the power, 2015-07-16 14:26:26]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-07-16 14:26:40]

Patchset 6 (id:??) landed as
https://crrev.com/07dc66dcd5d9bc266915d67142425dd92e1373ad
Cr-Commit-Position: refs/heads/master@{#29705}