Add ES2015 Function.name support to pattern and default parameter initializers

Add ES2015 Function.name support to pattern and default parameter initializers

Note that in these cases, we don't support computed property names yet, just
as we don't for object and class literals.

BUG=v8:3699, v8:4710
LOG=n

Committed: https://crrev.com/dadb3a5bb6e5631c81cb7d93710dca98f9e51890
Cr-Commit-Position: refs/heads/master@{#33562}

[adamk, 2016-01-27 02:42:11]

adamk@chromium.org changed reviewers:
+ caitpotter88@gmail.com, rossberg@chromium.org

[caitp (gmail), 2016-01-27 02:50:34]

non-binding lgtm

https://codereview.chromium.org/1634403002/diff/1/test/mjsunit/harmony/functi...
File test/mjsunit/harmony/function-name.js (right):

https://codereview.chromium.org/1634403002/diff/1/test/mjsunit/harmony/functi...
test/mjsunit/harmony/function-name.js:166: a = function() {},
What about `name: AssignmentExpression`-form binding properties? Even though
they should already work, it doesn't seem to be covered in this file (dunno if
it shows up elsewhere).

[adamk, 2016-01-27 18:33:55]

https://codereview.chromium.org/1634403002/diff/1/test/mjsunit/harmony/functi...
File test/mjsunit/harmony/function-name.js (right):

https://codereview.chromium.org/1634403002/diff/1/test/mjsunit/harmony/functi...
test/mjsunit/harmony/function-name.js:166: a = function() {},
On 2016/01/27 02:50:34, caitp wrote:
> What about `name: AssignmentExpression`-form binding properties? Even though
> they should already work, it doesn't seem to be covered in this file (dunno if
> it shows up elsewhere).

Added a few tests of this syntax too.

[rossberg, 2016-01-27 18:39:07]

lgtm

https://codereview.chromium.org/1634403002/diff/20001/test/mjsunit/harmony/fu...
File test/mjsunit/harmony/function-name.js (right):

https://codereview.chromium.org/1634403002/diff/20001/test/mjsunit/harmony/fu...
test/mjsunit/harmony/function-name.js:164: (function testObjectBindingPattern()
{
In all these cases, it might be good to also test the cases where the RHS is a
parenthesised expression, e.g.

f = (() => {})

Haven't checked what the spec actually prescribes in that case, but I assume
.name should not be set. It's worth having a test either way.

[adamk, 2016-01-27 18:46:38]

https://codereview.chromium.org/1634403002/diff/20001/test/mjsunit/harmony/fu...
File test/mjsunit/harmony/function-name.js (right):

https://codereview.chromium.org/1634403002/diff/20001/test/mjsunit/harmony/fu...
test/mjsunit/harmony/function-name.js:164: (function testObjectBindingPattern()
{
On 2016/01/27 18:39:07, rossberg wrote:
> In all these cases, it might be good to also test the cases where the RHS is a
> parenthesised expression, e.g.
> 
> f = (() => {})
> 
> Haven't checked what the spec actually prescribes in that case, but I assume
> .name should not be set. It's worth having a test either way.

Spec says that parentheses don't stop the name from applying:
http://tc39.github.io/ecma262/#sec-grouping-operator-static-semantics-isfunct...

Will add some more tests.

[adamk, 2016-01-27 18:51:20]

The CQ bit was checked by adamk@chromium.org

[adamk, 2016-01-27 18:51:20]

The patchset sent to the CQ was uploaded after l-g-t-m from
caitpotter88@gmail.com, rossberg@chromium.org
Link to the patchset: https://codereview.chromium.org/1634403002/#ps40001
(title: "Added parenthesized tests")

[commit-bot: I haz the power, 2016-01-27 18:51:26]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1634403002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1634403002/40001

[caitp (gmail), 2016-01-27 18:52:26]

On 2016/01/27 18:46:38, adamk wrote:
>
https://codereview.chromium.org/1634403002/diff/20001/test/mjsunit/harmony/fu...
> File test/mjsunit/harmony/function-name.js (right):
> 
>
https://codereview.chromium.org/1634403002/diff/20001/test/mjsunit/harmony/fu...
> test/mjsunit/harmony/function-name.js:164: (function
testObjectBindingPattern()
> {
> On 2016/01/27 18:39:07, rossberg wrote:
> > In all these cases, it might be good to also test the cases where the RHS is
a
> > parenthesised expression, e.g.
> > 
> > f = (() => {})
> > 
> > Haven't checked what the spec actually prescribes in that case, but I assume
> > .name should not be set. It's worth having a test either way.
> 
> Spec says that parentheses don't stop the name from applying:
>
http://tc39.github.io/ecma262/#sec-grouping-operator-static-semantics-isfunct...
> 
> Will add some more tests.

It doesn't apply in the case of a parenthesized comma-separated list of
expressions, though (another case to try, I'm not sure if that will work in the
preparser or not)

[adamk, 2016-01-27 18:55:04]

On 2016/01/27 18:52:26, caitp wrote:
> On 2016/01/27 18:46:38, adamk wrote:
> >
>
https://codereview.chromium.org/1634403002/diff/20001/test/mjsunit/harmony/fu...
> > File test/mjsunit/harmony/function-name.js (right):
> > 
> >
>
https://codereview.chromium.org/1634403002/diff/20001/test/mjsunit/harmony/fu...
> > test/mjsunit/harmony/function-name.js:164: (function
> testObjectBindingPattern()
> > {
> > On 2016/01/27 18:39:07, rossberg wrote:
> > > In all these cases, it might be good to also test the cases where the RHS
is
> a
> > > parenthesised expression, e.g.
> > > 
> > > f = (() => {})
> > > 
> > > Haven't checked what the spec actually prescribes in that case, but I
assume
> > > .name should not be set. It's worth having a test either way.
> > 
> > Spec says that parentheses don't stop the name from applying:
> >
>
http://tc39.github.io/ecma262/#sec-grouping-operator-static-semantics-isfunct...
> > 
> > Will add some more tests.
> 
> It doesn't apply in the case of a parenthesized comma-separated list of
> expressions, though (another case to try, I'm not sure if that will work in
the
> preparser or not)

Not sure how the preparser comes into this? No function names are set by the
preparser, so it doesn't really matter if it get this "wrong".

[caitp (gmail), 2016-01-27 18:56:20]

On 2016/01/27 18:55:04, adamk wrote:
> On 2016/01/27 18:52:26, caitp wrote:
> > It doesn't apply in the case of a parenthesized comma-separated list of
> > expressions, though (another case to try, I'm not sure if that will work in
> the
> > preparser or not)
> 
> Not sure how the preparser comes into this? No function names are set by the
> preparser, so it doesn't really matter if it get this "wrong".

Yeah, I realized that after posting, still doesn't hurt to test it, but your
call

[adamk, 2016-01-27 18:58:53]

On 2016/01/27 18:56:20, caitp wrote:
> On 2016/01/27 18:55:04, adamk wrote:
> > On 2016/01/27 18:52:26, caitp wrote:
> > > It doesn't apply in the case of a parenthesized comma-separated list of
> > > expressions, though (another case to try, I'm not sure if that will work
in
> > the
> > > preparser or not)
> > 
> > Not sure how the preparser comes into this? No function names are set by the
> > preparser, so it doesn't really matter if it get this "wrong".
> 
> Yeah, I realized that after posting, still doesn't hurt to test it, but your
> call

I don't see a particular reason to test that. I don't think we want negative
tests for all the millions of ways of _not_ applying a name to an anonymous
function expression.

[commit-bot: I haz the power, 2016-01-27 19:13:17]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-01-27 19:13:28]

Description was changed from

==========
Add ES2015 Function.name support to pattern and default parameter initializers

Note that in these cases, we don't support computed property names yet, just
as we don't for object and class literals.

BUG=v8:3699, v8:4710
LOG=n
==========

to

==========
Add ES2015 Function.name support to pattern and default parameter initializers

Note that in these cases, we don't support computed property names yet, just
as we don't for object and class literals.

BUG=v8:3699, v8:4710
LOG=n

Committed: https://crrev.com/dadb3a5bb6e5631c81cb7d93710dca98f9e51890
Cr-Commit-Position: refs/heads/master@{#33562}
==========

[commit-bot: I haz the power, 2016-01-27 19:13:29]

Patchset 3 (id:??) landed as
https://crrev.com/dadb3a5bb6e5631c81cb7d93710dca98f9e51890
Cr-Commit-Position: refs/heads/master@{#33562}