WIP parse destructuring assignment

WIP parse destructuring assignment

[caitp (gmail), 2015-08-18 17:50:09]

This is still a work in progress. It was an attempt to put the logic for this
into a more singular place. It didn't entirely work out that way.

My findings:

- The tracking of valid assignment targets from the original CL works a lot
better than this (but is much more spread out)

- The expression "flavor" idea may make it possible to support
CoverInitializedNames in AssignmentPatterns.

I seem to have caused a regression in `let []`, which now seems to parse as a
MemberExpression rather than a declaration. I originally published the diff to
figure out what caused that, and nothing really jumps out as having caused it.

There's another regression for CoverInitializedName in binding patterns (at
least in arrow function parameters), so currently a lot of test failures are
about that.

Probably need to write up a design doc to really figure out how this is going to
work.

As far as I can see, none of the other vendors have figured out a way to accept
CoverInitializedName in ObjectAssignmentPattern, but reject it in
ObjectLiterals, so for the time being I'm just putting that on hold. It's
difficult to get that one working.

[adamk, 2015-08-19 00:40:33]

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

[adamk, 2015-08-19 00:40:33]

Haven't dug in yet, but to your issue with 'let []': I suspect you're just
testing in sloppy mode. Here are my results with this patched in:

$ d8 --harmony-destructuring -e 'let [x] = [42]; print(x)'
unnamed:1: ReferenceError: let is not defined
let [x] = [1]; print(x)
^
ReferenceError: let is not defined
    at unnamed:1:1

$ d8 --harmony-destructuring -e '"use strict"; let [x] = [42]; print(x)'
42

$ d8 --harmony-destructuring --harmony-sloppy --harmony-sloppy-let -e 'let [x] =
[42]; print(x)'
42

[caitp (gmail), 2015-08-19 01:25:16]

On 2015/08/19 00:40:33, adamk wrote:
> Haven't dug in yet, but to your issue with 'let []': I suspect you're just
> testing in sloppy mode. Here are my results with this patched in:
> 
> $ d8 --harmony-destructuring -e 'let [x] = [42]; print(x)'
> unnamed:1: ReferenceError: let is not defined
> let [x] = [1]; print(x)
> ^
> ReferenceError: let is not defined
>     at unnamed:1:1
> 
> $ d8 --harmony-destructuring -e '"use strict"; let [x] = [42]; print(x)'
> 42
> 
> $ d8 --harmony-destructuring --harmony-sloppy --harmony-sloppy-let -e 'let [x]
=
> [42]; print(x)'
> 42

No, it's actual test cases in the tree. The thing it breaks on mostly is
rest/spread elements, which it runs into during ParsePrimaryExpression(). It is
possible it's broken upstream, but i haven't tested on master, so i assume it's
this code that broke it.