The existing implementation of this AO lives in Interpreter::create(),
which makes it impossible to use without also constructing an
Interpreter.
This patch adds a new Realm::initialize_host_defined_realm() and takes
the global object and global this customization steps as Function
callback objects. This will be used by LibWeb to create realms during
Document construction.
Note that we cannot use CompareTypedArrayElements until the change-
array-by-copy proposal picks up the change to no longer throw with
detached array buffers.
By aligning Array.prototype.sort with the spec, this removes the direct
invocation of CompareArrayElements from array_merge_sort. This opens the
door for TypedArray to use SortIndexedProperties as well because now
array_merge_sort does not assume what kind of array it is invoked with.
Further, this addresses a FIXME to avoid an extra JS heap allocation.
This isn't actually much of an issue because if the LHS side value is -0
and the RHS value is +0, errantly returning 0 in the comparison function
here has the same effect as correctly returning -1. In both cases, the
-0 is left on the LHS.
This isn't called out in TR-35, but before ICU even looks at CLDR data,
it adds a hard-coded set of default patterns to each locale's calendar.
It has done this since 2006 when its DateTimeFormat feature was first
created. Several test262 tests depend on this, which under ECMA-402,
falls into "implementation defined" behavior. For compatibility, we
can do the same in LibUnicode.
The Intl mathematical value is much like ECMA-262's mathematical value
in that it is meant to represent an arbitrarily precise number. The Intl
MV further allows positive/negative infinity, negative zero, and NaN.
This implementation is *not* arbitrarily precise. Rather, it is a
replacement for the use of Value within Intl.NumberFormat. The exact
syntax of the Intl MV is still being worked on, but abstracting this
away into its own class will allow hooking in the finalized Intl MV
more easily, and makes implementing Intl.NumberFormat.formatRange
easier.
Note the methods added here are essentially the same as the static
helpers in Intl/NumberFormat.cpp.
After the Intl MV is implemented, returning a copy of the desired value
here may involve copying non-trivial data. Instead, return an enum to
indicate which decision was made.
This becomes more of an issue when implementing the Intl mathematical
value, where negative zero is treated as a special enum value. In that
case, we already previously changed the value from -0 to +0 in step 1b.
Entering the branch for step 4 will then set it back to -0.
The math that follows after these steps worked fine with both +0/-0, but
assertions will be reached in the Intl MV implementation.
These were changed to i8 while investigating the issues fixed by commit
9e50f25. When [[RoundingIncrement]] is implemented, some of these will
be invoked with [[RoundingIncrement]]'s value, which can be up to 5000.
Change these to i32, and wrap them with AK::Checked for good measure.
Also change a couple helpers that are always comparing against zero to
not need an explicit check.
The largest exponents we compute are on the order of 10^21 (governed by
the maximumSignificantDigits option, which has a max value of 21). That
is too large to fit into the i64 we were using when multiplying this
exponent by the value to be formatted.
Instead, split up the logic to multiply that value by this exponent
based on the value's underlying type:
Number: Do not cast the result of pow() to an i64, and perform the
follow-up multiplication with doubles.
BigInt: Do not use pow(). Instead, compute the exponent as a BigInt
from the start, then perform the follow-up multiplication with that
BigInt.
Makes it much easier to scroll through the file while comparing to the
spec. Proposals are inserted alphabetically as that's where they will
likely end up once merged into the main spec.
Makes it much easier to scroll through the file while comparing to the
spec. Proposals are inserted alphabetically as that's where they will
likely end up once merged into the main spec.
For example, consider the locales "en-u-nu-fullwide" or "en-u-nu-arab".
The CLDR only declares the "latn" numbering system for the "en" locale,
thus ResolveLocale would change the locale to "en-u-nu-latn". This patch
allows using non-latn numbering systems digits.
