This is basically just for consistency, it's quite strange to see
multiple AK container types next to each other, some with and some
without the namespace prefix - we're 'using AK::Foo;' a lot and should
leverage that. :^)
https://tc39.es/ecma262/#sec-properties-of-the-regexp-prototype-object
The RegExp prototype object:
- is an ordinary object.
- is not a RegExp instance and does not have a [[RegExpMatcher]]
internal slot or any of the other internal slots of RegExp instance
objects.
In other words: no need to have RegExpPrototype inherit from
RegExpObject (we weren't even calling its initialize()).
https://tc39.es/ecma262/#sec-properties-of-the-array-prototype-object
The Array prototype object: [...] is an Array exotic object and has the
internal methods specified for such objects.
NOTE: The Array prototype object is specified to be an Array exotic
object to ensure compatibility with ECMAScript code that was created
prior to the ECMAScript 2015 specification.
(...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.
This was not implementing the following part of the spec correctly:
27. For each integer i such that i ≥ 1 and i ≤ n, do
a. Let captureI be ith element of r's captures List.
b. If captureI is undefined, let capturedValue be undefined.
Expecting a capture group match to exist for each of the RegExp's
capture groups would assert in Vector's operator[] if that's not the
case, for example:
/(foo)(bar)?/.exec("foo")
Append undefined instead.
Fixes#5256.
We were calling directly up to Cell, skipping over ScopeObject.
This made us not mark the scope chain parent for lexical environments,
sometimes causing them to get GC'd and use-after-free'd.
Found by Fuzzilli.
Fixes#5140.
We will now throw a RangeError in these cases:
* new TypedArray with >= INT32_MAX entries
* new TypedArray whose ArrayBuffer allocation size computation would
cause a 32-bit unsigned overflow.
If we have a function as class extends value, we still cannot assume
that it has a prototype property and that property has a function or
null as its value - blindly calling to_object() on it may fail.
Fixes#5075.
