Some of these are allocated upon initialization of the intrinsics, and
some lazily, but in neither case the getters actually return a nullptr.
This saves us a whole bunch of pointer dereferences (as NonnullGCPtr has
an `operator T&()`), and also has the interesting side effect of forcing
us to explicitly use the FunctionObject& overload of call(), as passing
a NonnullGCPtr is ambigous - it could implicitly be turned into a Value
_or_ a FunctionObject& (so we have to dereference manually).
This proposal has been merged into the main ECMA-402 spec. See:
4257160
Note this includes some editorial and normative changes made when the
proposal was merged into the main spec, but are not in the proposal spec
itself. In particular, the following AOs were changed:
PartitionNumberRangePattern (normative)
SetNumberFormatDigitOptions (editorial)
This is a normative change in the ECMA-402 spec. See:
50eb413
Note that this canonicalization already occurred. As the above commit
alludes to, we parse the rearguard format of the TZDB, so GMT is already
an alias to Etc/GMT. But it doesn't hurt to be explicit here.
This proposal has been merged into the main ECMA-262 spec. See:
4a32716
Note this includes some editorial changes made when the proposal was
merged into the main spec, but are not in the proposal spec.
This doesn't return a completion in the spec as it doesn't need to
propagate any errors. It's also unused right now, which is probably why
no one noticed.
We currently fully casefold the left- and right-hand sides to compare
two strings with case-insensitivity. Now, we casefold one code point at
a time, storing the result in a view for comparison, until we exhaust
both strings.
Comes with the usual benefit of saving some space on the stack, as well
as making a situation where both or neither Optionals hold a value
impossible.
The various unwrapping additions are required as we can no longer
construct a ThrowCompletionOr<T> from an Optional<T> - rightfully so.
This would never return an empty optional or non-numeric value, and in
fact every caller as_double()'d the value right away.
Let's make the type match reality instead :^)
u64 is not big enough to hold extremely large numbers, such as
4.192938423e+54. This would cause an integer underflow on the radix
index when performing something like `toString(36)` and thus cause an
OOB Array read.
