Assert that Evaluation in JSON.parse does not throw

[nicolo-ribaudo]

Closes #3392

When I opened that issue I was wrongly assuming that array literals longer than 2**32-1 would throw an error when evaluated. This is only true if the array contains holes in one of those too big indexes, which are not valid JSON syntax. What happens in the non-hole case is that the integer-indexed property gets defined without updating the array length, so it does not throw an error.

@michaelficarra and I went through the possible cases and we are confident this indeed never throws, so having ! instead of Completion(...) can help when reading the spec. If there were cases where it can throw, the current usage of Completion(...) is probably wrong anyway because you would want to re-throw the error (?), instead of using it as _unfiltered_.

[michaelficarra]

LGTM unless someone can find a way this Evaluation can actually throw.

And if it can, we'd probably want to change our handling of the throw completion anyway.

[jmdyck]

What happens in the non-hole case is that the integer-indexed property gets defined without updating the array length, so it does not throw an error.

So if the ArrayLiteral has more than 2^32-1 elements, the ones after the first 2^32-1 are evaluated, but ignored, is that it?

[michaelficarra]

@jmdyck Not exactly ignored. They still create properties but they don't attempt to update the length. The exception is holes, which do attempt to update the length and then throw.

[jmdyck]

They still create properties but they don't attempt to update the length.

Ah, I see now.