Normative: Remove ToUint32 from array literal evaluation

[littledan]

Previously, array literals (including spreads) had their indices and
lengths calculated with a ToUint32 operation. As Georg Neis noted
in #1095, such a calculation isn't quite right, as 2**32-1 is not
an array index. These semantics are unlikely to be observable in many
current JavaScript implementations due to resource limitations, but
the strange behavior may appear in future, resource-rich
implementations.

This patch specifies Georg Neis's suggestion for semantics: to write to
the length just in the case of elisions (regardless of where they are in
the Array literal), and don't bother to write to the length for writes for
ordinary elements (as Array indices will already lead to length updates).

As a bonus, the semantics for Array literals are singificantly simplified, involving
just one syntax-directed operation and pass rather than two. Note that, as before,
too-long Array literals throw only as a runtime exception, not as an early error.
This patch includes appropriate use of ? and ! in modified operations.

cc @allenwb @GeorgNeis @anba

[GeorgNeis]

Looks good, thanks!

[anba]

If ToUint32 is simply removed, the problem (unspecified behaviour for too large values when ToString is called) noted in #1095 (comment) will arise:

If you could reach it and the bogus ToUint32 that was inserted as a "fix" is removed then the property key that is set is currently unspecified because nextIndex + 1 will compute a mathematical value that is not a Number value and ToString doesn't specify how to convert such a value to a string value.

[littledan]

@anba I see; I was imagining that these were Numbers, but of course they are mathematical values. I'd be fine waiting to land this patch until after the fix to tc39/proposal-bigint#10 lands, which will make them Numbers.

[littledan]

@GeorgNeis and I discussed this change a bit further. Maybe the semantics here are a little off the mark--would it make more sense if we went with one version of @anba 's proposed semantics and used min(length, 2**32-1) when setting the length? This would give the final length that would result from the same series of property sets. The only exception we might want to make is if the array ends with several training commas which overflow--that could be considered equivalent to explicitly setting the length to a too-high value, and still throw. Any thoughts on these alternate semantics? If people like it, I can write this up into a new patch.

[littledan]

Uploaded a new version which attempts to specify the semantics from #1124 (comment) . @GeorgNeis What do you think?

[GeorgNeis]

s/exceeds/exceeding/
or better s/may throw in the case of an Array literal's/throws if the/

[littledan]

OK, @GeorgNeis had some more suggestions, which seem really on point to me. The result is a simpler and more obviously correct version, which is sightly different in semantics in even more obscure edge cases, but which I prefer. I've uploaded a commit from him to this PR, and edited the PR description to match the current proposal. If/when this PR lands, please squash the commits and use the description above as the commit message (minus the @mentions).

Given resource limits on all JS implementations Georg and I tested, we could not find a way to differentiate the current semantics from the semantics proposed in this patch (or the alternatives previously considered). I'd say, unfortunately, test262 tests will not be useful for this PR, and we should consider landing it without tests or implementations.

[littledan]

Any thoughts on this PR? What more is needed to decide whether it's ready to merge?

[ljharb]

Given that it's normative, it seems like it needs consensus (along with a rebase)

[littledan]

@ljharb Feel free to land all of those suggestions. Somehow, the GitHub UI won't let me commit them.