Remove SM staging tests wrongly testing invalid LHS

[nicolo-ribaudo]

It is an early error if the LHS of:

• ForOfStatement
• UpdateExpression
• AssignmentExpression
• DestructuringAssignmentTarget is not simple (i.e. not a function call).

[ljharb]

cc @dminor since at least one of these is marked as a regression test

[Ms2ger]

I'll deal with these next week

[Ms2ger]

The spec is wrong here: tc39/ecma262#2193

[nicolo-ribaudo]

These tests can be added once the spec is updated. We cannot have tests for something that has never even been presented in plenary, and even if we did then we'd need to have them with the appropriate feature flag and not mixing the feature with other unrelated assertions (in the for-of-iterator-close.js case).

[ljharb]

I’m not sure that level of rigor needs to hold for the staging directory.

[nicolo-ribaudo]

@ljharb I agree that there doesn't need to be much rigor to merge tests in the staging directory. However, it should be possible to fix them when needed.

The goal of the staging directory is for implementations to be able to share tests with each other before that they are "good enough" to be merged in the main test262 corpus. In this case we have already two consumers of test262 that correctly implement the spec and stumbled upon problems with the tests touched by this PR, because they are not what the spec asks us to implement.

Once somebody reports that a test is wrong, the test should be removed or fixed. This is the staging process working! The wrong test doesn't need to be caught by review of test262 maintainers, but it can be reviewed asynchronously by other implementations after that it is merged.

In this specific case, there is an open PR in the ecma262 repo that would make some of the wrong tests in this PR (but not the for-of one) correct. That PR has not even been presented to the committee yet, and looking at the comments in that PR there is no agreement on what the change should be: it's simply not possible to write tests for it yet.

However, given that the tests exist and maybe one day the spec will actually match what these tests say, we could add a feature flag like nonstandard-lhs-call, and consumers of test262 would know that they can skip tests marked as nonstandard-lhs-call. Again, I'm not saying that this should have done before merging the tests to staging, but that tests are meant to be refined once they are merged to staging.

---

EDIT: This was found by Babel and Porffor while running the updated tests, but it seems like they are not the only ones not passing it: