These new functions match the similarily named functions on `intl::NumberFormat`.
Also add some assertions to `NumberFormat::formatToParts()` when called with
decimal number strings to ensure non-finite number strings aren't used here,
because we always pass `Nothing()` for the number in this method.
Differential Revision: https://phabricator.services.mozilla.com/D119758
`NumberFormatterSkeleton::toRangeFormatter()` receives the two additional options
as extra parameters, because that's simpler to implement compared to storing the
`NumberRangeFormatOptions` struct in `NumberFormatterSkeleton`. We can revisit
this approach should `NumberRangeFormatOptions` ever get more additional options.
Differential Revision: https://phabricator.services.mozilla.com/D119757
Add `NumberPartSource` to `NumberPart` in preparation for part 18.
Also changes the underlying type of `NumberPartType` to `int16_t` to ensure the
size of `NumberPart` doesn't change on 32-bit platforms when adding
`NumberPartSource`. (Note: `sizeof(NumberPart)` is 16 on 64-platforms with or
without this change.)
Differential Revision: https://phabricator.services.mozilla.com/D119755
In the next part of this patch stack, we want to record the "source" of a
number part. The source is used when formatting number ranges to record if the
formatted number part belongs to the start resp. end of the number range.
Differential Revision: https://phabricator.services.mozilla.com/D119754
Change `GetPartTypeForNumberField` to a free function so a later part in this
patch stack can call it when processing number ranges.
Differential Revision: https://phabricator.services.mozilla.com/D119753
The "Intl.NumberFormat v3 API" proposal adds support to format arbitrarily large
decimal numbers. For example it's now possible to format the decimal number
1e1000 by passing the string `"1e1000"` to the `format` function.
`ToIntlMathematicalValue()` preprocesses the number as follows:
- Non-finite values (NaN and infinities) are always stored as `double` values.
- Positive and negative zero are also stored as `double` values.
- Non-decimal strings like `"0x10"` are stored as BigInts, because ICU only
supports decimal number strings.
- An error is thrown if the exponent is too large to workaround ICU limitations.
Normalising non-finite values and ±0 is done in preparation for part 17.
Differential Revision: https://phabricator.services.mozilla.com/D119752
First set of new options added in the "Intl.NumberFormat v3 API" proposal.
- All ICU rounding modes are added. (The Intl proposal doesn't support "HalfOdd".)
- The rounding mode names match the names in the Intl proposal, which are
different compared to the ICU names.
- Significant digits options are ignored when rounding increment is used. This is
an ICU limitation. The Intl proposal will throw an error if both options are
used at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D119745
Add `intl::NumberRangeFormat` based on the existing `intl::NumberFormat` class
and use it to implement `intl::PluralRules::SelectRange()`.
Most ICU number range formatting functions are still draft APIs and therefore
are guarded by `#ifndef U_HIDE_DRAFT_API`. Instead of requiring `mozilla::intl`
users to also use `U_HIDE_DRAFT_API`, add two additional preprocessor definitions
(`MOZ_INTL_PLURAL_RULES_HAS_SELECT_RANGE` and `MOZ_INTL_HAS_NUMBER_RANGE_FORMAT`).
When `MOZ_INTL_HAS_NUMBER_RANGE_FORMAT` isn't defined, `intl::NumberRangeFormat`
is an empty class. We could also hide the complete class if the preprocessor
guard isn't defined, but the other approach results in fewer `#ifdef` guards.
Differential Revision: https://phabricator.services.mozilla.com/D119742
SpiderMonkey requires the BCP 47 locale extensions, which involves iterating
over the keywords in ICU, and mapping them to the BCP 47 version. Specifically,
this will change the "phonebook" keyword to "phonebk". This should hopefully
expose a simpler API to SpiderMonkey, the only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D120903
This collator attempts to match the options bag from the Intl.Collator API
from ECMA-402. It is built to be compatible and consistent across both Gecko
code and SpiderMonkey code. Its behavior is designed to match ECMA-402.
Differential Revision: https://phabricator.services.mozilla.com/D120494
SpiderMonkey requires the BCP 47 locale extensions, which involves iterating
over the keywords in ICU, and mapping them to the BCP 47 version. Specifically,
this will change the "phonebook" keyword to "phonebk". This should hopefully
expose a simpler API to SpiderMonkey, the only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D120903
This collator attempts to match the options bag from the Intl.Collator API
from ECMA-402. It is built to be compatible and consistent across both Gecko
code and SpiderMonkey code. Its behavior is designed to match ECMA-402.
Differential Revision: https://phabricator.services.mozilla.com/D120494