Explicitly disallow constructing a CanonicalIndex from a floating point
type without going through a factory method that will throw when the
provided index cannot fit in a u32.
ErrorType::InvalidIndex does not encapsulate the reasons why an index
may be invalid. For example:
let array = new Uint8Array([1, 2, 3, 4, 5]);
array.with(10, 0);
Will currently yield:
[RangeError] Index must be a positive integer
Which is misleading because 10 *is* a positive integer.
Note that js_rope_string() has been folded into this, the old name was
misleading - it would not always create a rope string, only if both
sides are not empty strings. Use a three-argument create() overload
instead.
Three standalone Cell creation functions remain in the JS namespace:
- js_bigint()
- js_string()
- js_symbol()
All of them are leftovers from early iterations when LibJS still took
inspiration from JSC, which itself has jsString(). Nowadays, we pretty
much exclusively use static create() functions to construct types
allocated on the JS heap, and there's no reason to not do the same for
these.
Also change the return type from BigInt* to NonnullGCPtr<BigInt> while
we're here.
This is patch 1/3, replacement of js_string() and js_symbol() follow.
This makes more sense as an Object method rather than living within the
VM class for no good reason. Most of the other 7.3.xx AOs already work
the same way.
Also add spec comments while we're here.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
TypedArray constructors/prototypes are currently allocating within their
C++ constructor when trying to access the intrinsic base TypedArray. To
prevent this, construct these objects with an already-allocated base
TypedArray.
We are currently allocating in Set's constructor to create the set's
underlying Map. This can cause GC to occur before the member is actually
initialized, thus we will crash in Set::visit_edges trying to visit a
member that does not exist.
Instead, create the Map in Set::initialize, where we can allocate. Also
change Map to be stored as a normal JS heap-allocated object, rather
than as a stack variable.
The bytecode interpreter can execute generator functions while the AST
interpreter cannot. This simply makes it create a new bytecode
interpreter when one doesn't exist when executing a generator function.
Doing so makes it automatically switch to the bytecode interpreter to
execute any future code until it exits the generator.
