1. Allow Value(size_t) and use it for array length properties.
If an array length can't fit in an Int32 value, we shouldn't go out of
or way to force it into one. Instead, for values above INT32_MAX,
we simply store them as Double values.
2. Switch to generic indexed property storage for large arrays.
Previously we would always allocate array storage eagerly when the
length property was set. This meant that "a.length = 0x80000000" would
trivially DOS the engine on 32-bit since we don't have that much VM.
We now switch to generic storage when changing the length moves us over
the 4M entry mark.
Fixes#5986.
Just like to_size_t() - which was already removed in f369229 - this is
non-standard, use to_length() instead. One remaining use was removed,
and I'm glad it's gone. :^)
As @nico pointed out, 0.0 == -0.0 in C++, even though they are not
bitwise identical. Use the same trick as Value::is_negative_zero() to
really check for it.
This allows JS::Value(0.0) to correctly become an Int32-backed 0 value.
We now store 32-bit integers as 32-bit integers directly which avoids
having to convert them from doubles when they're only used as 32-bit
integers anyway. :^)
This patch feels a bit incomplete and there's a lot of opportunities
to take advantage of this information. We'll have to find and exploit
them eventually.
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
