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.
In the main spec, [[UseGrouping]] can be true or false. In V3, it may be
one of:
auto: Respect the per-locale preference for grouping.
always: Ignore per-locale preference for grouping and always insert
the grouping separator (note: true is now an alias for always).
min2: Ignore per-locale preference for grouping and only insert the
grouping separator if the primary group has at least 2 digits.
false: Ignore per-locale preference for grouping and never insert
the grouping separator.
This contains minimal changes to parse newly added and modified options
from the Intl.NumberFormat V3 proposal, while maintaining main spec
behavior in Intl.NumberFormat.prototype.format. The parsed options are
reflected only in Intl.NumberFormat.prototype.resolvedOptions and the js
REPL.
This prevents us from needing a sv suffix, and potentially reduces the
need to run generic code for a single character (as contains,
starts_with, ends_with etc. for a char will be just a length and
equality check).
No functional changes.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
These are mostly minor mistakes I've encountered while working on the
removal of StringView(char const*). The usage of builder.put_string over
Format<FormatString>::format is preferrable as it will avoid the
indirection altogether when there's no formatting to be done. Similarly,
there is no need to do format(builder, "{}", number) when
builder.put_u64(number) works equally well.
Additionally a few Strings where only constant strings were used are
replaced with StringViews.
This also allows removing a bit of a BigInt hack to resolve plurality of
BigInt numbers (because the AOs used in ResolvePlural support BigInt,
wherease the naive Unicode::select_pattern_with_plurality did not).
We use cardinal form here; the number format patterns in the CLDR align
with the cardinal form of the plural rules.
The NumberFormat spec casually indicates the need for a PluralRules
object without explicity saying so, with text such as:
"which may depend on x in languages having different plural forms."
Other implementations actually do create a PluralRules object to resolve
those cases with ResolvePlural. However, ResolvePlural doesn't need much
from PluralRules to operate, so this can be abstracted out for use in
NumberFormat without the need to allocate a PluralRules instance.
