Remove tests that allow ...[ and ...{ in object destructuring

[rwaldron]

per resolution of 16.i.h https://github.com/tc39/agendas/blob/master/2017/05.md

I'll work on this during my next cycle

[leobalter]

by object destructuring, this means rest operators (not spread) directly in object patterns for destructuring will only be valid with name identifiers.

let [{a, ...[]}] = [{/*...*/}]; // invalid
let {a, ...[]} = {/*...*/}; // invalid
let {a, ...[b]} = {/*...*/}; // invalid
let {a, ...{}} = {/*...*/}; // invalid
let {a, ...{b}} = {/*...*/}; // invalid
let {a, ...b} = {/*...*/}; // valid
let {...b} = {/*...*/}; // valid

This needs to wait the respective proposal to be fixed and match the references.

[rwaldron]

let {...[]} = {/*...*/}; // valid

I don't think that's correct. We need confirmation

This needs to wait the respective proposal to be fixed and match the references.

Everything I've reviewed so far has esid: pending

[leobalter]

I don't think that's correct. We need confirmation

right you are, my copy-pasta fault.

Everything I've reviewed so far has esid: pending

pending means only we don't have the reference on what the link would be in the specs yet. Still, we require a minimum spec text to reference each case. Of course, providing this in the info tag helps a lot.

[leobalter]

A few examples of test cases requiring a new review:

src/dstr-binding/obj-ptrn-rest-nested-obj.case
src/dstr-binding/obj-ptrn-rest-obj-nested-rest.case
src/dstr-binding/obj-ptrn-rest-obj-own-property.case

[rwaldron]

pending means only we don't have the reference on what the link would be in the specs yet

I know, but all the cases I've seen said "esid: pending", so there is no reason to...

This needs to wait the respective proposal to be fixed and match the references.

...

A few examples of test cases requiring a new review:
src/dstr-binding/obj-ptrn-rest-nested-obj.case
src/dstr-binding/obj-ptrn-rest-obj-nested-rest.case
src/dstr-binding/obj-ptrn-rest-obj-own-property.case

Yes, already removed in a branch.

[rwaldron]

I'll also include new negative syntax error tests.

[gsathya]

FYI, these are the obsolete tests that I had to disable in V8:
https://chromium-review.googlesource.com/c/550559/13/test/test262/test262.status

[rwaldron]

@gsathya thanks, you should update to latest test262 to get these changes: 29e69dd

[littledan]

Sorry, this is my fault on the late test262 update; I'll report any issues here if there are stray tests.

[rwaldron]

@littledan no problem!

[gsathya]

Thanks. If all the obsolete tests have been deleted, can this issue be closed now?

[littledan]

Have any tests been added that check that the old syntax is no longer allowed? I just upgraded V8 to the new version of test262, and Sathya's patch to use the new semantics hasn't landed yet, but the test262 tests all pass.

[gsathya]

Even with the latest roll, I had to skip a bunch of tests:
https://chromium-review.googlesource.com/c/550559/16/test/test262/test262.status

[littledan]

Note that the spec is not yet complete here. There is an open PR at tc39/proposal-object-rest-spread#51 which seems to have consensus among implementers at least.

[gsathya]

@leobalter Is this fixed now with #1187 ?

[leobalter]

yes, I believe we're all set on this. Thanks for the reminder.

[adrianheine]

@rwaldron Did you include those negative tests? I can't seem to find them.