Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-03 23:00:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Runtime/Intl/NumberFormat.cpp

1863 lines
78 KiB
C++
Raw Normal View History

LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
/*
Everywhere: Update copyrights with my new serenityos.org e-mail :^)
2022-01-31 13:07:22 -05:00
* Copyright (c) 2021-2022, Tim Flynn <trflynn89@serenityos.org>
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibJS: Relax integer size requirements on some NumberFormat helpers 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.
2022-07-18 08:56:56 -04:00
#include <AK/Checked.h>
LibJS: Implement number grouping for Intl.NumberFormat For example, in en-US, the number 123456 should be formatted as the string "123,456". In en-IN, it should be formatted as "1,23,456".
2021-11-13 23:59:12 -05:00
#include <AK/Utf8View.h>
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
#include <LibCrypto/BigInt/SignedBigInteger.h>
LibJS: Implement Intl.NumberFormat V3's [[TrailingZeroDisplay]] changes
2022-07-16 12:46:14 -04:00
#include <LibJS/Runtime/AbstractOperations.h>
LibJS: Implement Intl.NumberFormat.prototype.formatToParts
2021-11-13 11:33:55 -05:00
#include <LibJS/Runtime/Array.h>
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
#include <LibJS/Runtime/BigInt.h>
LibJS: Move Intl.NumberFormat's AOs to its object file
2021-09-11 11:09:18 -04:00
#include <LibJS/Runtime/GlobalObject.h>
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
#include <LibJS/Runtime/Intl/NumberFormat.h>
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
#include <LibJS/Runtime/Intl/NumberFormatFunction.h>
LibJS: Use Intl.PluralRules within Intl.NumberFormat 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.
2022-07-08 12:05:09 -04:00
#include <LibJS/Runtime/Intl/PluralRules.h>
LibJS: Move Intl.NumberFormat's AOs to its object file
2021-09-11 11:09:18 -04:00
#include <LibUnicode/CurrencyCode.h>
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
#include <math.h>
#include <stdlib.h>
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
namespace JS::Intl {
LibJS: Move some Intl.NumberFormat fields into a NumberFormatBase class Other Intl objects, such as PluralRules, are to be treated as a NumberFormat object in some AOs. There's only a handful of fields which are to be shared between those objects - move them to a base class for shared reuse. This also updates the couple of NumberFormat AOs that are meant to operate on these NumberFormat-like objects. Alternatively, we could just have objects like PluralRules inherit from NumberFormat directly. But that messes up the is<NumberFormat> runtime checks, so this feels safer.
2022-01-28 12:52:32 -05:00
NumberFormatBase::NumberFormatBase(Object& prototype)
: Object(prototype)
{
}
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
// 15 NumberFormat Objects, https://tc39.es/ecma402/#numberformat-objects
NumberFormat::NumberFormat(Object& prototype)
LibJS: Move some Intl.NumberFormat fields into a NumberFormatBase class Other Intl objects, such as PluralRules, are to be treated as a NumberFormat object in some AOs. There's only a handful of fields which are to be shared between those objects - move them to a base class for shared reuse. This also updates the couple of NumberFormat AOs that are meant to operate on these NumberFormat-like objects. Alternatively, we could just have objects like PluralRules inherit from NumberFormat directly. But that messes up the is<NumberFormat> runtime checks, so this feels safer.
2022-01-28 12:52:32 -05:00
: NumberFormatBase(prototype)
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
{
}
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
void NumberFormat::visit_edges(Cell::Visitor& visitor)
{
Base::visit_edges(visitor);
if (m_bound_format)
visitor.visit(m_bound_format);
}
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
void NumberFormat::set_style(StringView style)
{
if (style == "decimal"sv)
m_style = Style::Decimal;
else if (style == "percent"sv)
m_style = Style::Percent;
else if (style == "currency"sv)
m_style = Style::Currency;
else if (style == "unit"sv)
m_style = Style::Unit;
else
VERIFY_NOT_REACHED();
}
StringView NumberFormat::style_string() const
{
switch (m_style) {
case Style::Decimal:
return "decimal"sv;
case Style::Percent:
return "percent"sv;
case Style::Currency:
return "currency"sv;
case Style::Unit:
return "unit"sv;
default:
VERIFY_NOT_REACHED();
}
}
void NumberFormat::set_currency_display(StringView currency_display)
{
LibJS+LibUnicode: Don't remove {currency} keys in GetNumberFormatPattern In order to implement Intl.NumberFormat.prototype.formatToParts, do not replace {currency} keys in the format pattern before ECMA-402 tells us to. Otherwise, the array return by formatToParts will not contain the expected currency key. Early replacement was done to avoid resolving the currency display more than once, as it involves a couple of round trips to search through LibUnicode data. So this adds a non-standard method to NumberFormat to do this resolution and cache the result. Another side effect of this change is that LibUnicode must replace unit format patterns of the form "{0} {1}" during code generation. These were previously skipped during code generation because LibJS would just replace the keys with the currency display at runtime. But now that the currency display injection is delayed, any {0} or {1} keys in the format pattern will cause PartitionNumberPattern to abort.
2021-11-13 10:15:33 -05:00
m_resolved_currency_display.clear();
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
if (currency_display == "code"sv)
m_currency_display = CurrencyDisplay::Code;
else if (currency_display == "symbol"sv)
m_currency_display = CurrencyDisplay::Symbol;
else if (currency_display == "narrowSymbol"sv)
m_currency_display = CurrencyDisplay::NarrowSymbol;
else if (currency_display == "name"sv)
m_currency_display = CurrencyDisplay::Name;
else
VERIFY_NOT_REACHED();
}
LibJS+LibUnicode: Don't remove {currency} keys in GetNumberFormatPattern In order to implement Intl.NumberFormat.prototype.formatToParts, do not replace {currency} keys in the format pattern before ECMA-402 tells us to. Otherwise, the array return by formatToParts will not contain the expected currency key. Early replacement was done to avoid resolving the currency display more than once, as it involves a couple of round trips to search through LibUnicode data. So this adds a non-standard method to NumberFormat to do this resolution and cache the result. Another side effect of this change is that LibUnicode must replace unit format patterns of the form "{0} {1}" during code generation. These were previously skipped during code generation because LibJS would just replace the keys with the currency display at runtime. But now that the currency display injection is delayed, any {0} or {1} keys in the format pattern will cause PartitionNumberPattern to abort.
2021-11-13 10:15:33 -05:00
StringView NumberFormat::resolve_currency_display()
{
if (m_resolved_currency_display.has_value())
return *m_resolved_currency_display;
switch (currency_display()) {
case NumberFormat::CurrencyDisplay::Code:
m_resolved_currency_display = currency();
break;
case NumberFormat::CurrencyDisplay::Symbol:
LibJS+LibUnicode: Remove unnecessary locale currency mapping wrapper Before LibUnicode generated methods were weakly linked, we had a public method (get_locale_currency_mapping) for retrieving currency mappings. That method invoked one of several style-specific methods that only existed in the generated UnicodeLocale. One caveat of weakly linked functions is that every such function must have a public declaration. The result is that each of those styled methods are declared publicly, which makes the wrapper redundant because it is just as easy to invoke the method for the desired style.
2022-01-12 17:19:59 -05:00
m_resolved_currency_display = Unicode::get_locale_short_currency_mapping(data_locale(), currency());
LibJS+LibUnicode: Don't remove {currency} keys in GetNumberFormatPattern In order to implement Intl.NumberFormat.prototype.formatToParts, do not replace {currency} keys in the format pattern before ECMA-402 tells us to. Otherwise, the array return by formatToParts will not contain the expected currency key. Early replacement was done to avoid resolving the currency display more than once, as it involves a couple of round trips to search through LibUnicode data. So this adds a non-standard method to NumberFormat to do this resolution and cache the result. Another side effect of this change is that LibUnicode must replace unit format patterns of the form "{0} {1}" during code generation. These were previously skipped during code generation because LibJS would just replace the keys with the currency display at runtime. But now that the currency display injection is delayed, any {0} or {1} keys in the format pattern will cause PartitionNumberPattern to abort.
2021-11-13 10:15:33 -05:00
break;
case NumberFormat::CurrencyDisplay::NarrowSymbol:
LibJS+LibUnicode: Remove unnecessary locale currency mapping wrapper Before LibUnicode generated methods were weakly linked, we had a public method (get_locale_currency_mapping) for retrieving currency mappings. That method invoked one of several style-specific methods that only existed in the generated UnicodeLocale. One caveat of weakly linked functions is that every such function must have a public declaration. The result is that each of those styled methods are declared publicly, which makes the wrapper redundant because it is just as easy to invoke the method for the desired style.
2022-01-12 17:19:59 -05:00
m_resolved_currency_display = Unicode::get_locale_narrow_currency_mapping(data_locale(), currency());
LibJS+LibUnicode: Don't remove {currency} keys in GetNumberFormatPattern In order to implement Intl.NumberFormat.prototype.formatToParts, do not replace {currency} keys in the format pattern before ECMA-402 tells us to. Otherwise, the array return by formatToParts will not contain the expected currency key. Early replacement was done to avoid resolving the currency display more than once, as it involves a couple of round trips to search through LibUnicode data. So this adds a non-standard method to NumberFormat to do this resolution and cache the result. Another side effect of this change is that LibUnicode must replace unit format patterns of the form "{0} {1}" during code generation. These were previously skipped during code generation because LibJS would just replace the keys with the currency display at runtime. But now that the currency display injection is delayed, any {0} or {1} keys in the format pattern will cause PartitionNumberPattern to abort.
2021-11-13 10:15:33 -05:00
break;
case NumberFormat::CurrencyDisplay::Name:
LibJS+LibUnicode: Remove unnecessary locale currency mapping wrapper Before LibUnicode generated methods were weakly linked, we had a public method (get_locale_currency_mapping) for retrieving currency mappings. That method invoked one of several style-specific methods that only existed in the generated UnicodeLocale. One caveat of weakly linked functions is that every such function must have a public declaration. The result is that each of those styled methods are declared publicly, which makes the wrapper redundant because it is just as easy to invoke the method for the desired style.
2022-01-12 17:19:59 -05:00
m_resolved_currency_display = Unicode::get_locale_numeric_currency_mapping(data_locale(), currency());
LibJS+LibUnicode: Don't remove {currency} keys in GetNumberFormatPattern In order to implement Intl.NumberFormat.prototype.formatToParts, do not replace {currency} keys in the format pattern before ECMA-402 tells us to. Otherwise, the array return by formatToParts will not contain the expected currency key. Early replacement was done to avoid resolving the currency display more than once, as it involves a couple of round trips to search through LibUnicode data. So this adds a non-standard method to NumberFormat to do this resolution and cache the result. Another side effect of this change is that LibUnicode must replace unit format patterns of the form "{0} {1}" during code generation. These were previously skipped during code generation because LibJS would just replace the keys with the currency display at runtime. But now that the currency display injection is delayed, any {0} or {1} keys in the format pattern will cause PartitionNumberPattern to abort.
2021-11-13 10:15:33 -05:00
break;
default:
VERIFY_NOT_REACHED();
}
if (!m_resolved_currency_display.has_value())
m_resolved_currency_display = currency();
return *m_resolved_currency_display;
}
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
StringView NumberFormat::currency_display_string() const
{
VERIFY(m_currency_display.has_value());
switch (*m_currency_display) {
case CurrencyDisplay::Code:
return "code"sv;
case CurrencyDisplay::Symbol:
return "symbol"sv;
case CurrencyDisplay::NarrowSymbol:
return "narrowSymbol"sv;
case CurrencyDisplay::Name:
return "name"sv;
default:
VERIFY_NOT_REACHED();
}
}
void NumberFormat::set_currency_sign(StringView currency_sign)
{
if (currency_sign == "standard"sv)
m_currency_sign = CurrencySign::Standard;
else if (currency_sign == "accounting"sv)
m_currency_sign = CurrencySign::Accounting;
else
VERIFY_NOT_REACHED();
}
StringView NumberFormat::currency_sign_string() const
{
VERIFY(m_currency_sign.has_value());
switch (*m_currency_sign) {
case CurrencySign::Standard:
return "standard"sv;
case CurrencySign::Accounting:
return "accounting"sv;
default:
VERIFY_NOT_REACHED();
}
}
LibJS: Move some Intl.NumberFormat fields into a NumberFormatBase class Other Intl objects, such as PluralRules, are to be treated as a NumberFormat object in some AOs. There's only a handful of fields which are to be shared between those objects - move them to a base class for shared reuse. This also updates the couple of NumberFormat AOs that are meant to operate on these NumberFormat-like objects. Alternatively, we could just have objects like PluralRules inherit from NumberFormat directly. But that messes up the is<NumberFormat> runtime checks, so this feels safer.
2022-01-28 12:52:32 -05:00
StringView NumberFormatBase::rounding_type_string() const
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
{
switch (m_rounding_type) {
case RoundingType::SignificantDigits:
return "significantDigits"sv;
case RoundingType::FractionDigits:
return "fractionDigits"sv;
LibJS+js: Parse new constructor options from Intl.NumberFormat V3 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.
2022-07-12 13:18:23 -04:00
case RoundingType::MorePrecision:
return "morePrecision"sv;
case RoundingType::LessPrecision:
return "lessPrecision"sv;
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
default:
VERIFY_NOT_REACHED();
}
}
LibJS+js: Parse new constructor options from Intl.NumberFormat V3 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.
2022-07-12 13:18:23 -04:00
StringView NumberFormatBase::rounding_mode_string() const
{
switch (m_rounding_mode) {
case RoundingMode::Ceil:
return "ceil"sv;
case RoundingMode::Expand:
return "expand"sv;
case RoundingMode::Floor:
return "floor"sv;
case RoundingMode::HalfCeil:
return "halfCeil"sv;
case RoundingMode::HalfEven:
return "halfEven"sv;
case RoundingMode::HalfExpand:
return "halfExpand"sv;
case RoundingMode::HalfFloor:
return "halfFloor"sv;
case RoundingMode::HalfTrunc:
return "halfTrunc"sv;
case RoundingMode::Trunc:
return "trunc"sv;
default:
VERIFY_NOT_REACHED();
}
}
void NumberFormatBase::set_rounding_mode(StringView rounding_mode)
{
if (rounding_mode == "ceil"sv)
m_rounding_mode = RoundingMode::Ceil;
else if (rounding_mode == "expand"sv)
m_rounding_mode = RoundingMode::Expand;
else if (rounding_mode == "floor"sv)
m_rounding_mode = RoundingMode::Floor;
else if (rounding_mode == "halfCeil"sv)
m_rounding_mode = RoundingMode::HalfCeil;
else if (rounding_mode == "halfEven"sv)
m_rounding_mode = RoundingMode::HalfEven;
else if (rounding_mode == "halfExpand"sv)
m_rounding_mode = RoundingMode::HalfExpand;
else if (rounding_mode == "halfFloor"sv)
m_rounding_mode = RoundingMode::HalfFloor;
else if (rounding_mode == "halfTrunc"sv)
m_rounding_mode = RoundingMode::HalfTrunc;
else if (rounding_mode == "trunc"sv)
m_rounding_mode = RoundingMode::Trunc;
LibJS: Add missing VERIFY_NOT_REACHED in string-to-enum conversion Noticed this while working on [[RoundingMode]].
2022-07-18 08:38:47 -04:00
else
VERIFY_NOT_REACHED();
LibJS+js: Parse new constructor options from Intl.NumberFormat V3 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.
2022-07-12 13:18:23 -04:00
}
StringView NumberFormatBase::trailing_zero_display_string() const
{
switch (m_trailing_zero_display) {
case TrailingZeroDisplay::Auto:
return "auto"sv;
case TrailingZeroDisplay::StripIfInteger:
return "stripIfInteger"sv;
default:
VERIFY_NOT_REACHED();
}
}
void NumberFormatBase::set_trailing_zero_display(StringView trailing_zero_display)
{
if (trailing_zero_display == "auto"sv)
m_trailing_zero_display = TrailingZeroDisplay::Auto;
else if (trailing_zero_display == "stripIfInteger"sv)
m_trailing_zero_display = TrailingZeroDisplay::StripIfInteger;
else
VERIFY_NOT_REACHED();
}
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
Value NumberFormat::use_grouping_to_value(VM& vm) const
LibJS+js: Parse new constructor options from Intl.NumberFormat V3 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.
2022-07-12 13:18:23 -04:00
{
switch (m_use_grouping) {
case UseGrouping::Always:
return js_string(vm, "always"sv);
case UseGrouping::Auto:
return js_string(vm, "auto"sv);
case UseGrouping::Min2:
return js_string(vm, "min2"sv);
case UseGrouping::False:
return Value(false);
default:
VERIFY_NOT_REACHED();
}
}
void NumberFormat::set_use_grouping(StringOrBoolean const& use_grouping)
{
use_grouping.visit(
[this](StringView grouping) {
if (grouping == "always"sv)
m_use_grouping = UseGrouping::Always;
else if (grouping == "auto"sv)
m_use_grouping = UseGrouping::Auto;
else if (grouping == "min2"sv)
m_use_grouping = UseGrouping::Min2;
else
VERIFY_NOT_REACHED();
},
[this](bool grouping) {
VERIFY(!grouping);
m_use_grouping = UseGrouping::False;
});
}
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
void NumberFormat::set_notation(StringView notation)
{
if (notation == "standard"sv)
m_notation = Notation::Standard;
else if (notation == "scientific"sv)
m_notation = Notation::Scientific;
else if (notation == "engineering"sv)
m_notation = Notation::Engineering;
else if (notation == "compact"sv)
m_notation = Notation::Compact;
else
VERIFY_NOT_REACHED();
}
StringView NumberFormat::notation_string() const
{
switch (m_notation) {
case Notation::Standard:
return "standard"sv;
case Notation::Scientific:
return "scientific"sv;
case Notation::Engineering:
return "engineering"sv;
case Notation::Compact:
return "compact"sv;
default:
VERIFY_NOT_REACHED();
}
}
void NumberFormat::set_compact_display(StringView compact_display)
{
if (compact_display == "short"sv)
m_compact_display = CompactDisplay::Short;
else if (compact_display == "long"sv)
m_compact_display = CompactDisplay::Long;
else
VERIFY_NOT_REACHED();
}
StringView NumberFormat::compact_display_string() const
{
VERIFY(m_compact_display.has_value());
switch (*m_compact_display) {
case CompactDisplay::Short:
return "short"sv;
case CompactDisplay::Long:
return "long"sv;
default:
VERIFY_NOT_REACHED();
}
}
void NumberFormat::set_sign_display(StringView sign_display)
{
if (sign_display == "auto"sv)
m_sign_display = SignDisplay::Auto;
else if (sign_display == "never"sv)
m_sign_display = SignDisplay::Never;
else if (sign_display == "always"sv)
m_sign_display = SignDisplay::Always;
else if (sign_display == "exceptZero"sv)
m_sign_display = SignDisplay::ExceptZero;
LibJS+js: Parse new constructor options from Intl.NumberFormat V3 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.
2022-07-12 13:18:23 -04:00
else if (sign_display == "negative"sv)
m_sign_display = SignDisplay::Negative;
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
else
VERIFY_NOT_REACHED();
}
StringView NumberFormat::sign_display_string() const
{
switch (m_sign_display) {
case SignDisplay::Auto:
return "auto"sv;
case SignDisplay::Never:
return "never"sv;
case SignDisplay::Always:
return "always"sv;
case SignDisplay::ExceptZero:
return "exceptZero"sv;
LibJS+js: Parse new constructor options from Intl.NumberFormat V3 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.
2022-07-12 13:18:23 -04:00
case SignDisplay::Negative:
return "negative"sv;
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
default:
VERIFY_NOT_REACHED();
}
}
LibJS: Reorganize spec steps for Intl.NumberFormat This is an editorial change in the Intl spec: https://github.com/tc39/ecma402/commit/110cb1f
2022-03-15 10:58:47 -04:00
// 15.5.1 CurrencyDigits ( currency ), https://tc39.es/ecma402/#sec-currencydigits
LibJS: Move Intl.NumberFormat's AOs to its object file
2021-09-11 11:09:18 -04:00
int currency_digits(StringView currency)
{
// 1. If the ISO 4217 currency and funds code list contains currency as an alphabetic code, return the minor
// unit value corresponding to the currency from the list; otherwise, return 2.
if (auto currency_code = Unicode::get_currency_code(currency); currency_code.has_value())
return currency_code->minor_unit.value_or(2);
return 2;
}
LibJS: Reorganize spec steps for Intl.NumberFormat This is an editorial change in the Intl spec: https://github.com/tc39/ecma402/commit/110cb1f
2022-03-15 10:58:47 -04:00
// 15.5.3 FormatNumericToString ( intlObject, x ), https://tc39.es/ecma402/#sec-formatnumberstring
LibJS: Implement Intl.NumberFormat V3's [[RoundingPriority]] changes
2022-07-16 12:11:20 -04:00
// 1.1.5 FormatNumericToString ( intlObject, x ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-formatnumberstring
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
FormatResult format_numeric_to_string(NumberFormatBase const& intl_object, MathematicalValue number)
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
{
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
bool is_negative = false;
// 1. If x is negative-zero, then
if (number.is_negative_zero()) {
// a. Let isNegative be true.
is_negative = true;
// b. Let x be the mathematical value 0.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
number = MathematicalValue(0.0);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
}
// 2. Assert: x is a mathematical value.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
VERIFY(number.is_mathematical_value());
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 3. If x < 0, let isNegative be true; else let isNegative be false.
// FIXME: Spec issue: this step would override step 1a, see https://github.com/tc39/proposal-intl-numberformat-v3/issues/67
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if (number.is_negative()) {
LibJS: Avoid FormatNumericToString spec issue more carefully 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.
2022-07-19 09:59:34 -04:00
is_negative = true;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
LibJS: Avoid FormatNumericToString spec issue more carefully 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.
2022-07-19 09:59:34 -04:00
// 4. If isNegative, then
// a. Let x be -x.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
number.negate();
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 5. Let unsignedRoundingMode be GetUnsignedRoundingMode(intlObject.[[RoundingMode]], isNegative).
// FIXME: Spec issue: Intl.PluralRules does not have [[RoundingMode]], see https://github.com/tc39/proposal-intl-numberformat-v3/issues/103
Optional<NumberFormat::UnsignedRoundingMode> unsigned_rounding_mode;
if (intl_object.rounding_mode() != NumberFormat::RoundingMode::Invalid)
unsigned_rounding_mode = get_unsigned_rounding_mode(intl_object.rounding_mode(), is_negative);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
RawFormatResult result {};
LibJS: Move some Intl.NumberFormat fields into a NumberFormatBase class Other Intl objects, such as PluralRules, are to be treated as a NumberFormat object in some AOs. There's only a handful of fields which are to be shared between those objects - move them to a base class for shared reuse. This also updates the couple of NumberFormat AOs that are meant to operate on these NumberFormat-like objects. Alternatively, we could just have objects like PluralRules inherit from NumberFormat directly. But that messes up the is<NumberFormat> runtime checks, so this feels safer.
2022-01-28 12:52:32 -05:00
switch (intl_object.rounding_type()) {
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 6. If intlObject.[[RoundingType]] is significantDigits, then
LibJS: Move some Intl.NumberFormat fields into a NumberFormatBase class Other Intl objects, such as PluralRules, are to be treated as a NumberFormat object in some AOs. There's only a handful of fields which are to be shared between those objects - move them to a base class for shared reuse. This also updates the couple of NumberFormat AOs that are meant to operate on these NumberFormat-like objects. Alternatively, we could just have objects like PluralRules inherit from NumberFormat directly. But that messes up the is<NumberFormat> runtime checks, so this feels safer.
2022-01-28 12:52:32 -05:00
case NumberFormatBase::RoundingType::SignificantDigits:
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// a. Let result be ToRawPrecision(x, intlObject.[[MinimumSignificantDigits]], intlObject.[[MaximumSignificantDigits]], unsignedRoundingMode).
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result = to_raw_precision(number, intl_object.min_significant_digits(), intl_object.max_significant_digits(), unsigned_rounding_mode);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
break;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 7. Else if intlObject.[[RoundingType]] is fractionDigits, then
LibJS: Move some Intl.NumberFormat fields into a NumberFormatBase class Other Intl objects, such as PluralRules, are to be treated as a NumberFormat object in some AOs. There's only a handful of fields which are to be shared between those objects - move them to a base class for shared reuse. This also updates the couple of NumberFormat AOs that are meant to operate on these NumberFormat-like objects. Alternatively, we could just have objects like PluralRules inherit from NumberFormat directly. But that messes up the is<NumberFormat> runtime checks, so this feels safer.
2022-01-28 12:52:32 -05:00
case NumberFormatBase::RoundingType::FractionDigits:
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// a. Let result be ToRawFixed(x, intlObject.[[MinimumFractionDigits]], intlObject.[[MaximumFractionDigits]], intlObject.[[RoundingIncrement]], unsignedRoundingMode).
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result = to_raw_fixed(number, intl_object.min_fraction_digits(), intl_object.max_fraction_digits(), intl_object.rounding_increment(), unsigned_rounding_mode);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
break;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 8. Else,
LibJS: Implement Intl.NumberFormat V3's [[RoundingPriority]] changes
2022-07-16 12:11:20 -04:00
case NumberFormatBase::RoundingType::MorePrecision:
case NumberFormatBase::RoundingType::LessPrecision: {
// a. Let sResult be ToRawPrecision(x, intlObject.[[MinimumSignificantDigits]], intlObject.[[MaximumSignificantDigits]], unsignedRoundingMode).
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto significant_result = to_raw_precision(number, intl_object.min_significant_digits(), intl_object.max_significant_digits(), unsigned_rounding_mode);
LibJS: Implement Intl.NumberFormat V3's [[RoundingPriority]] changes
2022-07-16 12:11:20 -04:00
// b. Let fResult be ToRawFixed(x, intlObject.[[MinimumFractionDigits]], intlObject.[[MaximumFractionDigits]], intlObject.[[RoundingIncrement]], unsignedRoundingMode).
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto fraction_result = to_raw_fixed(number, intl_object.min_fraction_digits(), intl_object.max_fraction_digits(), intl_object.rounding_increment(), unsigned_rounding_mode);
LibJS: Implement Intl.NumberFormat V3's [[RoundingPriority]] changes
2022-07-16 12:11:20 -04:00
// c. If intlObj.[[RoundingType]] is morePrecision, then
if (intl_object.rounding_type() == NumberFormatBase::RoundingType::MorePrecision) {
// i. If sResult.[[RoundingMagnitude]] ≤ fResult.[[RoundingMagnitude]], then
if (significant_result.rounding_magnitude <= fraction_result.rounding_magnitude) {
// 1. Let result be sResult.
result = move(significant_result);
}
// ii. Else,
else {
// 2. Let result be fResult.
result = move(fraction_result);
}
}
// d. Else,
else {
// i. Assert: intlObj.[[RoundingType]] is lessPrecision.
VERIFY(intl_object.rounding_type() == NumberFormatBase::RoundingType::LessPrecision);
// ii. If sResult.[[RoundingMagnitude]] ≤ fResult.[[RoundingMagnitude]], then
if (significant_result.rounding_magnitude <= fraction_result.rounding_magnitude) {
// 1. Let result be fResult.
result = move(fraction_result);
}
// iii. Else,
else {
// 1. Let result be sResult.
result = move(significant_result);
}
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
break;
LibJS: Implement Intl.NumberFormat V3's [[RoundingPriority]] changes
2022-07-16 12:11:20 -04:00
}
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
default:
VERIFY_NOT_REACHED();
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 9. Let x be result.[[RoundedNumber]].
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
number = move(result.rounded_number);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 10. Let string be result.[[FormattedString]].
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
auto string = move(result.formatted_string);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 11. If intlObject.[[TrailingZeroDisplay]] is "stripIfInteger" and x modulo 1 = 0, then
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if ((intl_object.trailing_zero_display() == NumberFormat::TrailingZeroDisplay::StripIfInteger) && number.modulo_is_zero(1)) {
LibJS: Implement Intl.NumberFormat V3's [[TrailingZeroDisplay]] changes
2022-07-16 12:46:14 -04:00
// a. If string contains ".", then
if (auto index = string.find('.'); index.has_value()) {
// i. Set string to the substring of string from index 0 to the index of ".".
string = string.substring(0, *index);
}
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 12. Let int be result.[[IntegerDigitsCount]].
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
int digits = result.digits;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 13. Let minInteger be intlObject.[[MinimumIntegerDigits]].
LibJS: Move some Intl.NumberFormat fields into a NumberFormatBase class Other Intl objects, such as PluralRules, are to be treated as a NumberFormat object in some AOs. There's only a handful of fields which are to be shared between those objects - move them to a base class for shared reuse. This also updates the couple of NumberFormat AOs that are meant to operate on these NumberFormat-like objects. Alternatively, we could just have objects like PluralRules inherit from NumberFormat directly. But that messes up the is<NumberFormat> runtime checks, so this feels safer.
2022-01-28 12:52:32 -05:00
int min_integer = intl_object.min_integer_digits();
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 14. If int < minInteger, then
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
if (digits < min_integer) {
// a. Let forwardZeros be the String consisting of minInteger–int occurrences of the character "0".
auto forward_zeros = String::repeated('0', min_integer - digits);
// b. Set string to the string-concatenation of forwardZeros and string.
string = String::formatted("{}{}", forward_zeros, string);
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 15. If isNegative and x is 0, then
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if (is_negative && number.is_zero()) {
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// a. Let x be -0.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
number = MathematicalValue { MathematicalValue::Symbol::NegativeZero };
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
}
// 16. Else if isNegative, then
else if (is_negative) {
// b. Let x be -x.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
number.negate();
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 17. Return the Record { [[RoundedNumber]]: x, [[FormattedString]]: string }.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
return { move(string), move(number) };
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
LibJS: Reorganize spec steps for Intl.NumberFormat This is an editorial change in the Intl spec: https://github.com/tc39/ecma402/commit/110cb1f
2022-03-15 10:58:47 -04:00
// 15.5.4 PartitionNumberPattern ( numberFormat, x ), https://tc39.es/ecma402/#sec-partitionnumberpattern
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// 1.1.6 PartitionNumberPattern ( numberFormat, x ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-partitionnumberpattern
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
Vector<PatternPartition> partition_number_pattern(VM& vm, NumberFormat& number_format, MathematicalValue number)
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
{
// 1. Let exponent be 0.
int exponent = 0;
String formatted_string;
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// 2. If x is not-a-number, then
LibJS: Generalize Intl.NumberFormat to operate on Value types Intl.NumberFormat is meant to format both Number and BigInt types. To prepare for formatting BigInt types, this generalizes our NumberFormat implementation to operate on Value instances rather than doubles. All arithmetic is moved to static helpers that can now be updated with BigInt semantics.
2022-01-30 10:41:07 -05:00
if (number.is_nan()) {
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// a. Let n be an implementation- and locale-dependent (ILD) String value indicating the NaN value.
LibJS+LibUnicode: Generate unique numeric symbol lists There are 443 number system objects generated, each of which held an array of number system symbols. Of those 443 arrays, only 39 are unique. To uniquely store these, this change moves the generated NumericSymbol enumeration to the public LibUnicode/NumberFormat.h header with a pre- defined set of symbols that we need. This is to ensure the generated, unique arrays are created in a known order with known symbols. While it is unfortunate to no longer discover these symbols at generation time, it does allow us to ignore unwanted symbols and perform less string-to- enumeration conversions at lookup time.
2021-12-11 00:37:34 -05:00
formatted_string = Unicode::get_number_system_symbol(number_format.data_locale(), number_format.numbering_system(), Unicode::NumericSymbol::NaN).value_or("NaN"sv);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// 3. Else if x is positive-infinity, then
LibJS: Generalize Intl.NumberFormat to operate on Value types Intl.NumberFormat is meant to format both Number and BigInt types. To prepare for formatting BigInt types, this generalizes our NumberFormat implementation to operate on Value instances rather than doubles. All arithmetic is moved to static helpers that can now be updated with BigInt semantics.
2022-01-30 10:41:07 -05:00
else if (number.is_positive_infinity()) {
LibJS: Explicitly handle postive/negative infinity in Intl.NumberFormat This is a normative change in the Intl spec: https://github.com/tc39/ecma402/commit/f0f66cf Our implementation is unaffected by this change. LibUnicode pre-computes positive, negative, and signless format patterns, so we already format negative infinity correctly. Also, the CLDR does not contain specific locale-dependent strings for negative infinity anyways.
2021-12-31 16:10:54 -05:00
// a. Let n be an ILD String value indicating positive infinity.
LibJS+LibUnicode: Generate unique numeric symbol lists There are 443 number system objects generated, each of which held an array of number system symbols. Of those 443 arrays, only 39 are unique. To uniquely store these, this change moves the generated NumericSymbol enumeration to the public LibUnicode/NumberFormat.h header with a pre- defined set of symbols that we need. This is to ensure the generated, unique arrays are created in a known order with known symbols. While it is unfortunate to no longer discover these symbols at generation time, it does allow us to ignore unwanted symbols and perform less string-to- enumeration conversions at lookup time.
2021-12-11 00:37:34 -05:00
formatted_string = Unicode::get_number_system_symbol(number_format.data_locale(), number_format.numbering_system(), Unicode::NumericSymbol::Infinity).value_or("infinity"sv);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// 4. Else if x is negative-infinity, then
LibJS: Generalize Intl.NumberFormat to operate on Value types Intl.NumberFormat is meant to format both Number and BigInt types. To prepare for formatting BigInt types, this generalizes our NumberFormat implementation to operate on Value instances rather than doubles. All arithmetic is moved to static helpers that can now be updated with BigInt semantics.
2022-01-30 10:41:07 -05:00
else if (number.is_negative_infinity()) {
LibJS: Explicitly handle postive/negative infinity in Intl.NumberFormat This is a normative change in the Intl spec: https://github.com/tc39/ecma402/commit/f0f66cf Our implementation is unaffected by this change. LibUnicode pre-computes positive, negative, and signless format patterns, so we already format negative infinity correctly. Also, the CLDR does not contain specific locale-dependent strings for negative infinity anyways.
2021-12-31 16:10:54 -05:00
// a. Let n be an ILD String value indicating negative infinity.
// NOTE: The CLDR does not contain unique strings for negative infinity. The negative sign will
// be inserted by the pattern returned from GetNumberFormatPattern.
formatted_string = Unicode::get_number_system_symbol(number_format.data_locale(), number_format.numbering_system(), Unicode::NumericSymbol::Infinity).value_or("infinity"sv);
}
// 5. Else,
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
else {
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// a. If x is not negative-zero,
if (!number.is_negative_zero()) {
// i. Assert: x is a mathematical value.
VERIFY(number.is_mathematical_value());
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// ii. If numberFormat.[[Style]] is "percent", let x be 100 × x.
if (number_format.style() == NumberFormat::Style::Percent)
number = number.multiplied_by(100);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// iii. Let exponent be ComputeExponent(numberFormat, x).
exponent = compute_exponent(number_format, number);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// iv. Let x be x × 10^-exponent.
number = number.multiplied_by_power(-exponent);
}
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// b. Let formatNumberResult be FormatNumericToString(numberFormat, x).
auto format_number_result = format_numeric_to_string(number_format, move(number));
// c. Let n be formatNumberResult.[[FormattedString]].
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
formatted_string = move(format_number_result.formatted_string);
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// d. Let x be formatNumberResult.[[RoundedNumber]].
number = move(format_number_result.rounded_number);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
LibJS: Implement unit number formatting
2021-11-16 13:56:52 -05:00
Unicode::NumberFormat found_pattern {};
LibJS: Explicitly handle postive/negative infinity in Intl.NumberFormat This is a normative change in the Intl spec: https://github.com/tc39/ecma402/commit/f0f66cf Our implementation is unaffected by this change. LibUnicode pre-computes positive, negative, and signless format patterns, so we already format negative infinity correctly. Also, the CLDR does not contain specific locale-dependent strings for negative infinity anyways.
2021-12-31 16:10:54 -05:00
// 6. Let pattern be GetNumberFormatPattern(numberFormat, x).
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
auto pattern = get_number_format_pattern(vm, number_format, number, found_pattern);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
if (!pattern.has_value())
return {};
LibJS: Explicitly handle postive/negative infinity in Intl.NumberFormat This is a normative change in the Intl spec: https://github.com/tc39/ecma402/commit/f0f66cf Our implementation is unaffected by this change. LibUnicode pre-computes positive, negative, and signless format patterns, so we already format negative infinity correctly. Also, the CLDR does not contain specific locale-dependent strings for negative infinity anyways.
2021-12-31 16:10:54 -05:00
// 7. Let result be a new empty List.
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
Vector<PatternPartition> result;
LibJS: Explicitly handle postive/negative infinity in Intl.NumberFormat This is a normative change in the Intl spec: https://github.com/tc39/ecma402/commit/f0f66cf Our implementation is unaffected by this change. LibUnicode pre-computes positive, negative, and signless format patterns, so we already format negative infinity correctly. Also, the CLDR does not contain specific locale-dependent strings for negative infinity anyways.
2021-12-31 16:10:54 -05:00
// 8. Let patternParts be PartitionPattern(pattern).
LibJS+LibUnicode: Fully implement currency number formatting Currencies are a bit strange; the layout of currency data in the CLDR is not particularly compatible with what ECMA-402 expects. For example, the currency format in the "en" and "ar" locales for the Latin script are: en: "¤#,##0.00" ar: "¤\u00A0#,##0.00" Note how the "ar" locale has a non-breaking space after the currency symbol (¤), but "en" does not. This does not mean that this space will appear in the "ar"-formatted string, nor does it mean that a space won't appear in the "en"-formatted string. This is a runtime decision based on the currency display chosen by the user ("$" vs. "USD" vs. "US dollar") and other rules in the Unicode TR-35 spec. ECMA-402 shies away from the nuances here with "implementation-defined" steps. LibUnicode will store the data parsed from the CLDR however it is presented; making decisions about spacing, etc. will occur at runtime based on user input.
2021-11-12 23:16:37 -05:00
auto pattern_parts = pattern->visit([](auto const& p) { return partition_pattern(p); });
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Explicitly handle postive/negative infinity in Intl.NumberFormat This is a normative change in the Intl spec: https://github.com/tc39/ecma402/commit/f0f66cf Our implementation is unaffected by this change. LibUnicode pre-computes positive, negative, and signless format patterns, so we already format negative infinity correctly. Also, the CLDR does not contain specific locale-dependent strings for negative infinity anyways.
2021-12-31 16:10:54 -05:00
// 9. For each Record { [[Type]], [[Value]] } patternPart of patternParts, do
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
for (auto& pattern_part : pattern_parts) {
// a. Let p be patternPart.[[Type]].
auto part = pattern_part.type;
// b. If p is "literal", then
if (part == "literal"sv) {
// i. Append a new Record { [[Type]]: "literal", [[Value]]: patternPart.[[Value]] } as the last element of result.
LibJS: Avoid potential for dangling string views in partition patterns There aren't any dangling views in as of yet, but a subsequent commit will cause the "part" variable to be a view into an internally generated string. Therefore, after returning from PartitionNumberPattern, that view will be pointed at freed memory. This commit is to set the precendence of not returning a view to "part".
2021-11-13 12:53:28 -05:00
result.append({ "literal"sv, move(pattern_part.value) });
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
// c. Else if p is equal to "number", then
else if (part == "number"sv) {
// i. Let notationSubParts be PartitionNotationSubPattern(numberFormat, x, n, exponent).
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto notation_sub_parts = partition_notation_sub_pattern(number_format, number, formatted_string, exponent);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// ii. Append all elements of notationSubParts to result.
result.extend(move(notation_sub_parts));
}
// d. Else if p is equal to "plusSign", then
else if (part == "plusSign"sv) {
// i. Let plusSignSymbol be the ILND String representing the plus sign.
LibJS+LibUnicode: Generate unique numeric symbol lists There are 443 number system objects generated, each of which held an array of number system symbols. Of those 443 arrays, only 39 are unique. To uniquely store these, this change moves the generated NumericSymbol enumeration to the public LibUnicode/NumberFormat.h header with a pre- defined set of symbols that we need. This is to ensure the generated, unique arrays are created in a known order with known symbols. While it is unfortunate to no longer discover these symbols at generation time, it does allow us to ignore unwanted symbols and perform less string-to- enumeration conversions at lookup time.
2021-12-11 00:37:34 -05:00
auto plus_sign_symbol = Unicode::get_number_system_symbol(number_format.data_locale(), number_format.numbering_system(), Unicode::NumericSymbol::PlusSign).value_or("+"sv);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// ii. Append a new Record { [[Type]]: "plusSign", [[Value]]: plusSignSymbol } as the last element of result.
LibJS: Avoid potential for dangling string views in partition patterns There aren't any dangling views in as of yet, but a subsequent commit will cause the "part" variable to be a view into an internally generated string. Therefore, after returning from PartitionNumberPattern, that view will be pointed at freed memory. This commit is to set the precendence of not returning a view to "part".
2021-11-13 12:53:28 -05:00
result.append({ "plusSign"sv, plus_sign_symbol });
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
// e. Else if p is equal to "minusSign", then
else if (part == "minusSign"sv) {
// i. Let minusSignSymbol be the ILND String representing the minus sign.
LibJS+LibUnicode: Generate unique numeric symbol lists There are 443 number system objects generated, each of which held an array of number system symbols. Of those 443 arrays, only 39 are unique. To uniquely store these, this change moves the generated NumericSymbol enumeration to the public LibUnicode/NumberFormat.h header with a pre- defined set of symbols that we need. This is to ensure the generated, unique arrays are created in a known order with known symbols. While it is unfortunate to no longer discover these symbols at generation time, it does allow us to ignore unwanted symbols and perform less string-to- enumeration conversions at lookup time.
2021-12-11 00:37:34 -05:00
auto minus_sign_symbol = Unicode::get_number_system_symbol(number_format.data_locale(), number_format.numbering_system(), Unicode::NumericSymbol::MinusSign).value_or("-"sv);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// ii. Append a new Record { [[Type]]: "minusSign", [[Value]]: minusSignSymbol } as the last element of result.
LibJS: Avoid potential for dangling string views in partition patterns There aren't any dangling views in as of yet, but a subsequent commit will cause the "part" variable to be a view into an internally generated string. Therefore, after returning from PartitionNumberPattern, that view will be pointed at freed memory. This commit is to set the precendence of not returning a view to "part".
2021-11-13 12:53:28 -05:00
result.append({ "minusSign"sv, minus_sign_symbol });
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
// f. Else if p is equal to "percentSign" and numberFormat.[[Style]] is "percent", then
else if ((part == "percentSign"sv) && (number_format.style() == NumberFormat::Style::Percent)) {
// i. Let percentSignSymbol be the ILND String representing the percent sign.
LibJS+LibUnicode: Generate unique numeric symbol lists There are 443 number system objects generated, each of which held an array of number system symbols. Of those 443 arrays, only 39 are unique. To uniquely store these, this change moves the generated NumericSymbol enumeration to the public LibUnicode/NumberFormat.h header with a pre- defined set of symbols that we need. This is to ensure the generated, unique arrays are created in a known order with known symbols. While it is unfortunate to no longer discover these symbols at generation time, it does allow us to ignore unwanted symbols and perform less string-to- enumeration conversions at lookup time.
2021-12-11 00:37:34 -05:00
auto percent_sign_symbol = Unicode::get_number_system_symbol(number_format.data_locale(), number_format.numbering_system(), Unicode::NumericSymbol::PercentSign).value_or("%"sv);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// ii. Append a new Record { [[Type]]: "percentSign", [[Value]]: percentSignSymbol } as the last element of result.
LibJS: Avoid potential for dangling string views in partition patterns There aren't any dangling views in as of yet, but a subsequent commit will cause the "part" variable to be a view into an internally generated string. Therefore, after returning from PartitionNumberPattern, that view will be pointed at freed memory. This commit is to set the precendence of not returning a view to "part".
2021-11-13 12:53:28 -05:00
result.append({ "percentSign"sv, percent_sign_symbol });
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
// g. Else if p is equal to "unitPrefix" and numberFormat.[[Style]] is "unit", then
LibJS: Implement unit number formatting
2021-11-16 13:56:52 -05:00
// h. Else if p is equal to "unitSuffix" and numberFormat.[[Style]] is "unit", then
else if ((part.starts_with("unitIdentifier:"sv)) && (number_format.style() == NumberFormat::Style::Unit)) {
// Note: Our implementation combines "unitPrefix" and "unitSuffix" into one field, "unitIdentifier".
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Implement unit number formatting
2021-11-16 13:56:52 -05:00
auto identifier_index = part.substring_view("unitIdentifier:"sv.length()).to_uint();
VERIFY(identifier_index.has_value());
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// i. Let unit be numberFormat.[[Unit]].
// ii. Let unitDisplay be numberFormat.[[UnitDisplay]].
LibJS: Implement unit number formatting
2021-11-16 13:56:52 -05:00
// iii. Let mu be an ILD String value representing unit before x in unitDisplay form, which may depend on x in languages having different plural forms.
auto unit_identifier = found_pattern.identifiers[*identifier_index];
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Implement unit number formatting
2021-11-16 13:56:52 -05:00
// iv. Append a new Record { [[Type]]: "unit", [[Value]]: mu } as the last element of result.
result.append({ "unit"sv, unit_identifier });
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
// i. Else if p is equal to "currencyCode" and numberFormat.[[Style]] is "currency", then
// j. Else if p is equal to "currencyPrefix" and numberFormat.[[Style]] is "currency", then
// k. Else if p is equal to "currencySuffix" and numberFormat.[[Style]] is "currency", then
LibJS+LibUnicode: Fully implement currency number formatting Currencies are a bit strange; the layout of currency data in the CLDR is not particularly compatible with what ECMA-402 expects. For example, the currency format in the "en" and "ar" locales for the Latin script are: en: "¤#,##0.00" ar: "¤\u00A0#,##0.00" Note how the "ar" locale has a non-breaking space after the currency symbol (¤), but "en" does not. This does not mean that this space will appear in the "ar"-formatted string, nor does it mean that a space won't appear in the "en"-formatted string. This is a runtime decision based on the currency display chosen by the user ("$" vs. "USD" vs. "US dollar") and other rules in the Unicode TR-35 spec. ECMA-402 shies away from the nuances here with "implementation-defined" steps. LibUnicode will store the data parsed from the CLDR however it is presented; making decisions about spacing, etc. will occur at runtime based on user input.
2021-11-12 23:16:37 -05:00
//
LibJS+LibUnicode: Don't remove {currency} keys in GetNumberFormatPattern In order to implement Intl.NumberFormat.prototype.formatToParts, do not replace {currency} keys in the format pattern before ECMA-402 tells us to. Otherwise, the array return by formatToParts will not contain the expected currency key. Early replacement was done to avoid resolving the currency display more than once, as it involves a couple of round trips to search through LibUnicode data. So this adds a non-standard method to NumberFormat to do this resolution and cache the result. Another side effect of this change is that LibUnicode must replace unit format patterns of the form "{0} {1}" during code generation. These were previously skipped during code generation because LibJS would just replace the keys with the currency display at runtime. But now that the currency display injection is delayed, any {0} or {1} keys in the format pattern will cause PartitionNumberPattern to abort.
2021-11-13 10:15:33 -05:00
// Note: Our implementation manipulates the format string to inject/remove spacing around the
// currency code during GetNumberFormatPattern so that we do not have to do currency
// display / plurality lookups more than once.
else if ((part == "currency"sv) && (number_format.style() == NumberFormat::Style::Currency)) {
result.append({ "currency"sv, number_format.resolve_currency_display() });
}
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// l. Else,
else {
// i. Let unknown be an ILND String based on x and p.
// ii. Append a new Record { [[Type]]: "unknown", [[Value]]: unknown } as the last element of result.
// LibUnicode doesn't generate any "unknown" patterns.
VERIFY_NOT_REACHED();
}
}
LibJS: Explicitly handle postive/negative infinity in Intl.NumberFormat This is a normative change in the Intl spec: https://github.com/tc39/ecma402/commit/f0f66cf Our implementation is unaffected by this change. LibUnicode pre-computes positive, negative, and signless format patterns, so we already format negative infinity correctly. Also, the CLDR does not contain specific locale-dependent strings for negative infinity anyways.
2021-12-31 16:10:54 -05:00
// 10. Return result.
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
return result;
}
LibJS: Implement Intl.NumberFormat V3's [[UseGrouping]] changes 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.
2022-07-12 14:30:30 -04:00
static Vector<StringView> separate_integer_into_groups(Unicode::NumberGroupings const& grouping_sizes, StringView integer, NumberFormat::UseGrouping use_grouping)
LibJS: Implement number grouping for Intl.NumberFormat For example, in en-US, the number 123456 should be formatted as the string "123,456". In en-IN, it should be formatted as "1,23,456".
2021-11-13 23:59:12 -05:00
{
Utf8View utf8_integer { integer };
LibJS: Respect per-locale minimum grouping digits when number formatting
2022-01-27 12:45:23 -05:00
if (utf8_integer.length() <= grouping_sizes.primary_grouping_size)
return { integer };
size_t index = utf8_integer.length() - grouping_sizes.primary_grouping_size;
LibJS: Implement Intl.NumberFormat V3's [[UseGrouping]] changes 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.
2022-07-12 14:30:30 -04:00
switch (use_grouping) {
case NumberFormat::UseGrouping::Min2:
if (utf8_integer.length() < 5)
return { integer };
break;
case NumberFormat::UseGrouping::Auto:
if (index < grouping_sizes.minimum_grouping_digits)
return { integer };
break;
case NumberFormat::UseGrouping::Always:
break;
default:
VERIFY_NOT_REACHED();
}
LibJS: Respect per-locale minimum grouping digits when number formatting
2022-01-27 12:45:23 -05:00
LibJS: Implement number grouping for Intl.NumberFormat For example, in en-US, the number 123456 should be formatted as the string "123,456". In en-IN, it should be formatted as "1,23,456".
2021-11-13 23:59:12 -05:00
Vector<StringView> groups;
auto add_group = [&](size_t index, size_t length) {
groups.prepend(utf8_integer.unicode_substring_view(index, length).as_string());
};
LibJS: Respect per-locale minimum grouping digits when number formatting
2022-01-27 12:45:23 -05:00
add_group(index, grouping_sizes.primary_grouping_size);
LibJS: Implement number grouping for Intl.NumberFormat For example, in en-US, the number 123456 should be formatted as the string "123,456". In en-IN, it should be formatted as "1,23,456".
2021-11-13 23:59:12 -05:00
LibJS: Respect per-locale minimum grouping digits when number formatting
2022-01-27 12:45:23 -05:00
while (index > grouping_sizes.secondary_grouping_size) {
index -= grouping_sizes.secondary_grouping_size;
add_group(index, grouping_sizes.secondary_grouping_size);
LibJS: Implement number grouping for Intl.NumberFormat For example, in en-US, the number 123456 should be formatted as the string "123,456". In en-IN, it should be formatted as "1,23,456".
2021-11-13 23:59:12 -05:00
}
LibJS: Respect per-locale minimum grouping digits when number formatting
2022-01-27 12:45:23 -05:00
if (index > 0)
add_group(0, index);
LibJS: Implement number grouping for Intl.NumberFormat For example, in en-US, the number 123456 should be formatted as the string "123,456". In en-IN, it should be formatted as "1,23,456".
2021-11-13 23:59:12 -05:00
return groups;
}
LibJS: Reorganize spec steps for Intl.NumberFormat This is an editorial change in the Intl spec: https://github.com/tc39/ecma402/commit/110cb1f
2022-03-15 10:58:47 -04:00
// 15.5.5 PartitionNotationSubPattern ( numberFormat, x, n, exponent ), https://tc39.es/ecma402/#sec-partitionnotationsubpattern
LibJS: Implement Intl.NumberFormat V3's [[UseGrouping]] changes 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.
2022-07-12 14:30:30 -04:00
// 1.1.7 PartitionNotationSubPattern ( numberFormat, x, n, exponent ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-partitionnotationsubpattern
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
Vector<PatternPartition> partition_notation_sub_pattern(NumberFormat& number_format, MathematicalValue const& number, String formatted_string, int exponent)
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
{
// 1. Let result be a new empty List.
Vector<PatternPartition> result;
LibJS: Implement number grouping for Intl.NumberFormat For example, in en-US, the number 123456 should be formatted as the string "123,456". In en-IN, it should be formatted as "1,23,456".
2021-11-13 23:59:12 -05:00
auto grouping_sizes = Unicode::get_number_system_groupings(number_format.data_locale(), number_format.numbering_system());
if (!grouping_sizes.has_value())
return {};
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 2. If x is NaN, then
LibJS: Generalize Intl.NumberFormat to operate on Value types Intl.NumberFormat is meant to format both Number and BigInt types. To prepare for formatting BigInt types, this generalizes our NumberFormat implementation to operate on Value instances rather than doubles. All arithmetic is moved to static helpers that can now be updated with BigInt semantics.
2022-01-30 10:41:07 -05:00
if (number.is_nan()) {
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// a. Append a new Record { [[Type]]: "nan", [[Value]]: n } as the last element of result.
result.append({ "nan"sv, move(formatted_string) });
}
// 3. Else if x is a non-finite Number, then
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
else if (number.is_positive_infinity() || number.is_negative_infinity()) {
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// a. Append a new Record { [[Type]]: "infinity", [[Value]]: n } as the last element of result.
result.append({ "infinity"sv, move(formatted_string) });
}
// 4. Else,
else {
// a. Let notationSubPattern be GetNotationSubPattern(numberFormat, exponent).
auto notation_sub_pattern = get_notation_sub_pattern(number_format, exponent);
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
if (!notation_sub_pattern.has_value())
return {};
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// b. Let patternParts be PartitionPattern(notationSubPattern).
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
auto pattern_parts = partition_pattern(*notation_sub_pattern);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// c. For each Record { [[Type]], [[Value]] } patternPart of patternParts, do
for (auto& pattern_part : pattern_parts) {
// i. Let p be patternPart.[[Type]].
auto part = pattern_part.type;
// ii. If p is "literal", then
if (part == "literal"sv) {
// 1. Append a new Record { [[Type]]: "literal", [[Value]]: patternPart.[[Value]] } as the last element of result.
LibJS: Avoid potential for dangling string views in partition patterns There aren't any dangling views in as of yet, but a subsequent commit will cause the "part" variable to be a view into an internally generated string. Therefore, after returning from PartitionNumberPattern, that view will be pointed at freed memory. This commit is to set the precendence of not returning a view to "part".
2021-11-13 12:53:28 -05:00
result.append({ "literal"sv, move(pattern_part.value) });
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
// iii. Else if p is equal to "number", then
else if (part == "number"sv) {
LibJS: Reorganize spec steps for Intl.NumberFormat This is an editorial change in the Intl spec: https://github.com/tc39/ecma402/commit/110cb1f
2022-03-15 10:58:47 -04:00
// 1. If the numberFormat.[[NumberingSystem]] matches one of the values in the "Numbering System" column of Table 12 below, then
// a. Let digits be a List whose 10 String valued elements are the UTF-16 string representations of the 10 digits specified in the "Digits" column of the matching row in Table 12.
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// b. Replace each digit in n with the value of digits[digit].
// 2. Else use an implementation dependent algorithm to map n to the appropriate representation of n in the given numbering system.
LibJS+LibUnicode: Move replacement of number system digits to LibUnicode There are a few algorithms in TR-35 that need to replace digits before returning any results to callers. For example, when formatting time zone offsets, a string like "GMT+12:34" must have its digits replaced with the default numbering system for the desired locale.
2022-01-11 10:07:45 -05:00
formatted_string = Unicode::replace_digits_for_number_system(number_format.numbering_system(), formatted_string);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 3. Let decimalSepIndex be StringIndexOf(n, ".", 0).
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
auto decimal_sep_index = formatted_string.find('.');
StringView integer;
Optional<StringView> fraction;
// 4. If decimalSepIndex > 0, then
if (decimal_sep_index.has_value() && (*decimal_sep_index > 0)) {
// a. Let integer be the substring of n from position 0, inclusive, to position decimalSepIndex, exclusive.
integer = formatted_string.substring_view(0, *decimal_sep_index);
// b. Let fraction be the substring of n from position decimalSepIndex, exclusive, to the end of n.
fraction = formatted_string.substring_view(*decimal_sep_index + 1);
}
// 5. Else,
else {
// a. Let integer be n.
integer = formatted_string;
// b. Let fraction be undefined.
}
LibJS: Implement Intl.NumberFormat V3's [[UseGrouping]] changes 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.
2022-07-12 14:30:30 -04:00
// 6. If the numberFormat.[[UseGrouping]] is false, then
if (number_format.use_grouping() == NumberFormat::UseGrouping::False) {
// a. Append a new Record { [[Type]]: "integer", [[Value]]: integer } as the last element of result.
result.append({ "integer"sv, integer });
}
// 7. Else,
else {
LibJS: Implement number grouping for Intl.NumberFormat For example, in en-US, the number 123456 should be formatted as the string "123,456". In en-IN, it should be formatted as "1,23,456".
2021-11-13 23:59:12 -05:00
// a. Let groupSepSymbol be the implementation-, locale-, and numbering system-dependent (ILND) String representing the grouping separator.
LibJS+LibUnicode: Generate unique numeric symbol lists There are 443 number system objects generated, each of which held an array of number system symbols. Of those 443 arrays, only 39 are unique. To uniquely store these, this change moves the generated NumericSymbol enumeration to the public LibUnicode/NumberFormat.h header with a pre- defined set of symbols that we need. This is to ensure the generated, unique arrays are created in a known order with known symbols. While it is unfortunate to no longer discover these symbols at generation time, it does allow us to ignore unwanted symbols and perform less string-to- enumeration conversions at lookup time.
2021-12-11 00:37:34 -05:00
auto group_sep_symbol = Unicode::get_number_system_symbol(number_format.data_locale(), number_format.numbering_system(), Unicode::NumericSymbol::Group).value_or(","sv);
LibJS: Implement number grouping for Intl.NumberFormat For example, in en-US, the number 123456 should be formatted as the string "123,456". In en-IN, it should be formatted as "1,23,456".
2021-11-13 23:59:12 -05:00
LibJS: Implement Intl.NumberFormat V3's [[UseGrouping]] changes 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.
2022-07-12 14:30:30 -04:00
// b. Let groups be a List whose elements are, in left to right order, the substrings defined by ILND set of locations within the integer, which may depend on the value of numberFormat.[[UseGrouping]].
auto groups = separate_integer_into_groups(*grouping_sizes, integer, number_format.use_grouping());
LibJS: Implement number grouping for Intl.NumberFormat For example, in en-US, the number 123456 should be formatted as the string "123,456". In en-IN, it should be formatted as "1,23,456".
2021-11-13 23:59:12 -05:00
// c. Assert: The number of elements in groups List is greater than 0.
VERIFY(!groups.is_empty());
// d. Repeat, while groups List is not empty,
while (!groups.is_empty()) {
// i. Remove the first element from groups and let integerGroup be the value of that element.
auto integer_group = groups.take_first();
// ii. Append a new Record { [[Type]]: "integer", [[Value]]: integerGroup } as the last element of result.
result.append({ "integer"sv, integer_group });
// iii. If groups List is not empty, then
if (!groups.is_empty()) {
// i. Append a new Record { [[Type]]: "group", [[Value]]: groupSepSymbol } as the last element of result.
result.append({ "group"sv, group_sep_symbol });
}
}
}
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 8. If fraction is not undefined, then
if (fraction.has_value()) {
// a. Let decimalSepSymbol be the ILND String representing the decimal separator.
LibJS+LibUnicode: Generate unique numeric symbol lists There are 443 number system objects generated, each of which held an array of number system symbols. Of those 443 arrays, only 39 are unique. To uniquely store these, this change moves the generated NumericSymbol enumeration to the public LibUnicode/NumberFormat.h header with a pre- defined set of symbols that we need. This is to ensure the generated, unique arrays are created in a known order with known symbols. While it is unfortunate to no longer discover these symbols at generation time, it does allow us to ignore unwanted symbols and perform less string-to- enumeration conversions at lookup time.
2021-12-11 00:37:34 -05:00
auto decimal_sep_symbol = Unicode::get_number_system_symbol(number_format.data_locale(), number_format.numbering_system(), Unicode::NumericSymbol::Decimal).value_or("."sv);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// b. Append a new Record { [[Type]]: "decimal", [[Value]]: decimalSepSymbol } as the last element of result.
result.append({ "decimal"sv, decimal_sep_symbol });
// c. Append a new Record { [[Type]]: "fraction", [[Value]]: fraction } as the last element of result.
result.append({ "fraction"sv, fraction.release_value() });
}
}
// iv. Else if p is equal to "compactSymbol", then
// v. Else if p is equal to "compactName", then
LibJS+LibUnicode: Support multiple identifiers within format pattern This wasn't the case for compact patterns, but unit patterns can contain multiple (up to 2, really) identifiers that must each be recognized by LibJS. Each generated NumberFormat object now stores an array of identifiers parsed. The format pattern itself is encoded with the index into this array for that identifier, e.g. the compact format string "0K" will become "{number}{compactIdentifier:0}".
2021-11-16 13:53:45 -05:00
else if (part.starts_with("compactIdentifier:"sv)) {
LibJS: Implement compact formatting for Intl.NumberFormat
2021-11-15 11:07:41 -05:00
// Note: Our implementation combines "compactSymbol" and "compactName" into one field, "compactIdentifier".
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS+LibUnicode: Support multiple identifiers within format pattern This wasn't the case for compact patterns, but unit patterns can contain multiple (up to 2, really) identifiers that must each be recognized by LibJS. Each generated NumberFormat object now stores an array of identifiers parsed. The format pattern itself is encoded with the index into this array for that identifier, e.g. the compact format string "0K" will become "{number}{compactIdentifier:0}".
2021-11-16 13:53:45 -05:00
auto identifier_index = part.substring_view("compactIdentifier:"sv.length()).to_uint();
VERIFY(identifier_index.has_value());
LibJS: Implement compact formatting for Intl.NumberFormat
2021-11-15 11:07:41 -05:00
// 1. Let compactSymbol be an ILD string representing exponent in short form, which may depend on x in languages having different plural forms. The implementation must be able to provide this string, or else the pattern would not have a "{compactSymbol}" placeholder.
LibJS+LibUnicode: Support multiple identifiers within format pattern This wasn't the case for compact patterns, but unit patterns can contain multiple (up to 2, really) identifiers that must each be recognized by LibJS. Each generated NumberFormat object now stores an array of identifiers parsed. The format pattern itself is encoded with the index into this array for that identifier, e.g. the compact format string "0K" will become "{number}{compactIdentifier:0}".
2021-11-16 13:53:45 -05:00
auto compact_identifier = number_format.compact_format().identifiers[*identifier_index];
LibJS: Implement compact formatting for Intl.NumberFormat
2021-11-15 11:07:41 -05:00
// 2. Append a new Record { [[Type]]: "compact", [[Value]]: compactSymbol } as the last element of result.
result.append({ "compact"sv, compact_identifier });
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
// vi. Else if p is equal to "scientificSeparator", then
else if (part == "scientificSeparator"sv) {
// 1. Let scientificSeparator be the ILND String representing the exponent separator.
LibJS+LibUnicode: Generate unique numeric symbol lists There are 443 number system objects generated, each of which held an array of number system symbols. Of those 443 arrays, only 39 are unique. To uniquely store these, this change moves the generated NumericSymbol enumeration to the public LibUnicode/NumberFormat.h header with a pre- defined set of symbols that we need. This is to ensure the generated, unique arrays are created in a known order with known symbols. While it is unfortunate to no longer discover these symbols at generation time, it does allow us to ignore unwanted symbols and perform less string-to- enumeration conversions at lookup time.
2021-12-11 00:37:34 -05:00
auto scientific_separator = Unicode::get_number_system_symbol(number_format.data_locale(), number_format.numbering_system(), Unicode::NumericSymbol::Exponential).value_or("E"sv);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 2. Append a new Record { [[Type]]: "exponentSeparator", [[Value]]: scientificSeparator } as the last element of result.
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
result.append({ "exponentSeparator"sv, scientific_separator });
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
// vii. Else if p is equal to "scientificExponent", then
else if (part == "scientificExponent"sv) {
// 1. If exponent < 0, then
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
if (exponent < 0) {
// a. Let minusSignSymbol be the ILND String representing the minus sign.
LibJS+LibUnicode: Generate unique numeric symbol lists There are 443 number system objects generated, each of which held an array of number system symbols. Of those 443 arrays, only 39 are unique. To uniquely store these, this change moves the generated NumericSymbol enumeration to the public LibUnicode/NumberFormat.h header with a pre- defined set of symbols that we need. This is to ensure the generated, unique arrays are created in a known order with known symbols. While it is unfortunate to no longer discover these symbols at generation time, it does allow us to ignore unwanted symbols and perform less string-to- enumeration conversions at lookup time.
2021-12-11 00:37:34 -05:00
auto minus_sign_symbol = Unicode::get_number_system_symbol(number_format.data_locale(), number_format.numbering_system(), Unicode::NumericSymbol::MinusSign).value_or("-"sv);
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
// b. Append a new Record { [[Type]]: "exponentMinusSign", [[Value]]: minusSignSymbol } as the last element of result.
result.append({ "exponentMinusSign"sv, minus_sign_symbol });
// c. Let exponent be -exponent.
exponent *= -1;
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 2. Let exponentResult be ToRawFixed(exponent, 0, 0, 1, undefined).
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto exponent_value = MathematicalValue { static_cast<double>(exponent) };
auto exponent_result = to_raw_fixed(exponent_value, 0, 0, 1, {});
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
// FIXME: The spec does not say to do this, but all of major engines perform this replacement.
// Without this, formatting with non-Latin numbering systems will produce non-localized results.
LibJS+LibUnicode: Move replacement of number system digits to LibUnicode There are a few algorithms in TR-35 that need to replace digits before returning any results to callers. For example, when formatting time zone offsets, a string like "GMT+12:34" must have its digits replaced with the default numbering system for the desired locale.
2022-01-11 10:07:45 -05:00
exponent_result.formatted_string = Unicode::replace_digits_for_number_system(number_format.numbering_system(), exponent_result.formatted_string);
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
// 3. Append a new Record { [[Type]]: "exponentInteger", [[Value]]: exponentResult.[[FormattedString]] } as the last element of result.
result.append({ "exponentInteger"sv, move(exponent_result.formatted_string) });
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
// viii. Else,
else {
// 1. Let unknown be an ILND String based on x and p.
// 2. Append a new Record { [[Type]]: "unknown", [[Value]]: unknown } as the last element of result.
LibJS: Remove FIXME comment from PartitionNotationSubPattern AO All possible patterns generated by LibUnicode are now handled. We have a similar VERIFY_NOT_REACHED in PartitionNumberPattern.
2021-11-15 11:38:23 -05:00
// LibUnicode doesn't generate any "unknown" patterns.
VERIFY_NOT_REACHED();
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
}
}
// 5. Return result.
return result;
}
LibJS: Reorganize spec steps for Intl.NumberFormat This is an editorial change in the Intl spec: https://github.com/tc39/ecma402/commit/110cb1f
2022-03-15 10:58:47 -04:00
// 15.5.6 FormatNumeric ( numberFormat, x ), https://tc39.es/ecma402/#sec-formatnumber
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
String format_numeric(VM& vm, NumberFormat& number_format, MathematicalValue number)
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
{
// 1. Let parts be ? PartitionNumberPattern(numberFormat, x).
// Note: Our implementation of PartitionNumberPattern does not throw.
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
auto parts = partition_number_pattern(vm, number_format, move(number));
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 2. Let result be the empty String.
StringBuilder result;
// 3. For each Record { [[Type]], [[Value]] } part in parts, do
for (auto& part : parts) {
// a. Set result to the string-concatenation of result and part.[[Value]].
result.append(move(part.value));
}
// 4. Return result.
return result.build();
}
LibJS: Reorganize spec steps for Intl.NumberFormat This is an editorial change in the Intl spec: https://github.com/tc39/ecma402/commit/110cb1f
2022-03-15 10:58:47 -04:00
// 15.5.7 FormatNumericToParts ( numberFormat, x ), https://tc39.es/ecma402/#sec-formatnumbertoparts
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
Array* format_numeric_to_parts(VM& vm, NumberFormat& number_format, MathematicalValue number)
LibJS: Implement Intl.NumberFormat.prototype.formatToParts
2021-11-13 11:33:55 -05:00
{
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
auto& realm = *vm.current_realm();
LibJS: Implement Intl.NumberFormat.prototype.formatToParts
2021-11-13 11:33:55 -05:00
// 1. Let parts be ? PartitionNumberPattern(numberFormat, x).
// Note: Our implementation of PartitionNumberPattern does not throw.
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
auto parts = partition_number_pattern(vm, number_format, move(number));
LibJS: Implement Intl.NumberFormat.prototype.formatToParts
2021-11-13 11:33:55 -05:00
LibJS: Explicitly indicate infallible incovations These are editorial changes in the Intl spec. See: https://github.com/tc39/ecma402/commit/6804096 https://github.com/tc39/ecma402/commit/6361167 https://github.com/tc39/ecma402/commit/8718171 https://github.com/tc39/ecma402/commit/fd37cb4 https://github.com/tc39/ecma402/commit/00fcfb0 https://github.com/tc39/ecma402/commit/913f832
2022-03-28 08:30:48 -04:00
// 2. Let result be ! ArrayCreate(0).
LibJS+LibWeb: Replace GlobalObject with Realm in create() functions This is a continuation of the previous two commits. As allocating a JS cell already primarily involves a realm instead of a global object, and we'll need to pass one to the allocate() function itself eventually (it's bridged via the global object right now), the create() functions need to receive a realm as well. The plan is for this to be the highest-level function that actually receives a realm and passes it around, AOs on an even higher level will use the "current realm" concept via VM::current_realm() as that's what the spec assumes; passing around realms (or global objects, for that matter) on higher AO levels is pointless and unlike for allocating individual objects, which may happen outside of regular JS execution, we don't need control over the specific realm that is being used there.
2022-08-16 00:20:49 +01:00
auto* result = MUST(Array::create(realm, 0));
LibJS: Implement Intl.NumberFormat.prototype.formatToParts
2021-11-13 11:33:55 -05:00
// 3. Let n be 0.
size_t n = 0;
// 4. For each Record { [[Type]], [[Value]] } part in parts, do
for (auto& part : parts) {
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// a. Let O be OrdinaryObjectCreate(%Object.prototype%).
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
auto* object = Object::create(realm, realm.intrinsics().object_prototype());
LibJS: Implement Intl.NumberFormat.prototype.formatToParts
2021-11-13 11:33:55 -05:00
// b. Perform ! CreateDataPropertyOrThrow(O, "type", part.[[Type]]).
MUST(object->create_data_property_or_throw(vm.names.type, js_string(vm, part.type)));
// c. Perform ! CreateDataPropertyOrThrow(O, "value", part.[[Value]]).
MUST(object->create_data_property_or_throw(vm.names.value, js_string(vm, move(part.value))));
// d. Perform ! CreateDataPropertyOrThrow(result, ! ToString(n), O).
MUST(result->create_data_property_or_throw(n, object));
// e. Increment n by 1.
++n;
}
// 5. Return result.
return result;
}
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
static String cut_trailing_zeroes(StringView string, int cut)
{
// These steps are exactly the same between ToRawPrecision and ToRawFixed.
// Repeat, while cut > 0 and the last character of m is "0",
while ((cut > 0) && string.ends_with('0')) {
// Remove the last character from m.
string = string.substring_view(0, string.length() - 1);
// Decrease cut by 1.
--cut;
}
// If the last character of m is ".", then
if (string.ends_with('.')) {
// Remove the last character from m.
string = string.substring_view(0, string.length() - 1);
}
return string.to_string();
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
enum class PreferredResult {
LessThanNumber,
GreaterThanNumber,
};
// ToRawPrecisionFn, https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#eqn-ToRawPrecisionFn
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
static auto to_raw_precision_function(MathematicalValue const& number, int precision, PreferredResult mode)
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
{
struct {
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
MathematicalValue number;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
int exponent { 0 };
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
MathematicalValue rounded;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
} result {};
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.exponent = number.logarithmic_floor();
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
if (number.is_number()) {
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = number.divided_by_power(result.exponent - precision + 1);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
switch (mode) {
case PreferredResult::LessThanNumber:
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = MathematicalValue { floor(result.number.as_number()) };
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
break;
case PreferredResult::GreaterThanNumber:
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = MathematicalValue { ceil(result.number.as_number()) };
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
break;
}
} else {
// NOTE: In order to round the BigInt to the proper precision, this computation is initially off by a
// factor of 10. This lets us inspect the ones digit and then round up if needed.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = number.divided_by_power(result.exponent - precision);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// FIXME: Can we do this without string conversion?
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto digits = result.number.to_string();
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
auto digit = digits.substring_view(digits.length() - 1);
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = result.number.divided_by(10);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
if (mode == PreferredResult::GreaterThanNumber && digit.to_uint().value() != 0)
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = result.number.plus(1);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
}
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.rounded = result.number.multiplied_by_power(result.exponent - precision + 1);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
return result;
}
LibJS: Reorganize spec steps for Intl.NumberFormat This is an editorial change in the Intl spec: https://github.com/tc39/ecma402/commit/110cb1f
2022-03-15 10:58:47 -04:00
// 15.5.8 ToRawPrecision ( x, minPrecision, maxPrecision ), https://tc39.es/ecma402/#sec-torawprecision
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 1.1.10 ToRawPrecision ( x, minPrecision, maxPrecision, unsignedRoundingMode ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-torawprecision
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
RawFormatResult to_raw_precision(MathematicalValue const& number, int min_precision, int max_precision, Optional<NumberFormat::UnsignedRoundingMode> const& unsigned_rounding_mode)
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
{
RawFormatResult result {};
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 1. Let p be maxPrecision.
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
int precision = max_precision;
int exponent = 0;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 2. If x = 0, then
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if (number.is_zero()) {
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// a. Let m be the String consisting of p occurrences of the character "0".
result.formatted_string = String::repeated('0', precision);
// b. Let e be 0.
exponent = 0;
// c. Let xFinal be 0.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.rounded_number = MathematicalValue { 0.0 };
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 3. Else,
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
else {
// FIXME: The result of these steps isn't entirely accurate for large values of 'p' (which
// defaults to 21, resulting in numbers on the order of 10^21). Either AK::format or
// our Number::toString AO (double_to_string in Value.cpp) will need to be improved
// to produce more accurate results.
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// a. Let n1 and e1 each be an integer and r1 a mathematical value, with r1 = ToRawPrecisionFn(n1, e1, p), such that r1 ≤ x and r1 is maximized.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto [number1, exponent1, rounded1] = to_raw_precision_function(number, precision, PreferredResult::LessThanNumber);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// b. Let n2 and e2 each be an integer and r2 a mathematical value, with r2 = ToRawPrecisionFn(n2, e2, p), such that r2 ≥ x and r2 is minimized.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto [number2, exponent2, rounded2] = to_raw_precision_function(number, precision, PreferredResult::GreaterThanNumber);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// c. Let r be ApplyUnsignedRoundingMode(x, r1, r2, unsignedRoundingMode).
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto rounded = apply_unsigned_rounding_mode(number, rounded1, rounded2, unsigned_rounding_mode);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
MathematicalValue n;
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// d. If r is r1, then
LibJS: Return an enum from ApplyUnsignedRoundingMode 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.
2022-07-19 12:27:54 -04:00
if (rounded == RoundingDecision::LowerValue) {
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// i. Let n be n1.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
n = move(number1);
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// ii. Let e be e1.
exponent = exponent1;
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// iii. Let xFinal be r1.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.rounded_number = move(rounded1);
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// e. Else,
else {
// i. Let n be n2.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
n = move(number2);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// ii. Let e be e2.
exponent = exponent2;
// iii. Let xFinal be r2.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.rounded_number = move(rounded2);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
}
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// f. Let m be the String consisting of the digits of the decimal representation of n (in order, with no leading zeroes).
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.formatted_string = n.to_string();
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 4. If e ≥ p–1, then
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
if (exponent >= (precision - 1)) {
// a. Let m be the string-concatenation of m and e–p+1 occurrences of the character "0".
result.formatted_string = String::formatted(
"{}{}",
result.formatted_string,
String::repeated('0', exponent - precision + 1));
// b. Let int be e+1.
result.digits = exponent + 1;
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 5. Else if e ≥ 0, then
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
else if (exponent >= 0) {
// a. Let m be the string-concatenation of the first e+1 characters of m, the character ".", and the remaining p–(e+1) characters of m.
result.formatted_string = String::formatted(
"{}.{}",
result.formatted_string.substring_view(0, exponent + 1),
result.formatted_string.substring_view(exponent + 1));
// b. Let int be e+1.
result.digits = exponent + 1;
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 6. Else,
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
else {
// a. Assert: e < 0.
LibJS: Use consistent ASCII case-transformation and string language Also update the incorrect spec link for IsWellFormedCurrencyCode. These are editorial changes in the Intl spec. See: https://github.com/tc39/ecma402/commit/6939b44 https://github.com/tc39/ecma402/commit/3a775eb https://github.com/tc39/ecma402/commit/97a7940 https://github.com/tc39/ecma402/commit/129c790 https://github.com/tc39/ecma402/commit/42ec908 https://github.com/tc39/ecma402/commit/ea25c36
2022-03-28 09:53:06 -04:00
// b. Let m be the string-concatenation of "0.", –(e+1) occurrences of the character "0", and m.
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
result.formatted_string = String::formatted(
"0.{}{}",
String::repeated('0', -1 * (exponent + 1)),
result.formatted_string);
// c. Let int be 1.
result.digits = 1;
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 7. If m contains the character ".", and maxPrecision > minPrecision, then
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
if (result.formatted_string.contains('.') && (max_precision > min_precision)) {
// a. Let cut be maxPrecision – minPrecision.
int cut = max_precision - min_precision;
LibJS: Update ToRawPrecision / ToRawFixed AO spec comments This is a normative change in the Intl spec: https://github.com/tc39/ecma402/commit/f0f66cf There are two main changes here: 1. Converting BigInt/Number objects to mathematical values. 2. A change in how ToRawPrecision computes its exponent and significant digits. For (1), we do not yet support BigInt number formatting, thus already have coerced Number objects to a double. When BigInt is supported, the number passed into these methods will likely still be a Value, thus can be coereced then. For (2), our implementation already returns the expected edge-case results pointed out on the spec PR.
2022-01-02 12:45:52 -05:00
// Steps 8b-8c are implemented by cut_trailing_zeroes.
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
result.formatted_string = cut_trailing_zeroes(result.formatted_string, cut);
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 8. Return the Record { [[FormattedString]]: m, [[RoundedNumber]]: xFinal, [[IntegerDigitsCount]]: int, [[RoundingMagnitude]]: e–p+1 }.
LibJS: Implement Intl.NumberFormat V3's [[RoundingPriority]] changes
2022-07-16 12:11:20 -04:00
result.rounding_magnitude = exponent - precision + 1;
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
return result;
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// ToRawFixedFn, https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#eqn-ToRawFixedFn
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
static auto to_raw_fixed_function(MathematicalValue const& number, int fraction, int rounding_increment, PreferredResult mode)
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
{
struct {
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
MathematicalValue number;
MathematicalValue rounded;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
} result {};
if (number.is_number()) {
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = number.multiplied_by_power(fraction);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
switch (mode) {
case PreferredResult::LessThanNumber:
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = MathematicalValue { floor(result.number.as_number()) };
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
break;
case PreferredResult::GreaterThanNumber:
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = MathematicalValue { ceil(result.number.as_number()) };
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
break;
}
} else {
// NOTE: In order to round the BigInt to the proper precision, this computation is initially off by a
// factor of 10. This lets us inspect the ones digit and then round up if needed.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = number.multiplied_by_power(fraction - 1);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// FIXME: Can we do this without string conversion?
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto digits = result.number.to_string();
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
auto digit = digits.substring_view(digits.length() - 1);
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = result.number.multiplied_by(10);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
if (mode == PreferredResult::GreaterThanNumber && digit.to_uint().value() != 0)
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = result.number.plus(1);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
}
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
while (!result.number.modulo_is_zero(rounding_increment)) {
LibJS: Implement Intl.NumberFormat V3's [[RoundingIncrement]] changes
2022-07-18 10:01:02 -04:00
switch (mode) {
case PreferredResult::LessThanNumber:
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = result.number.minus(1);
LibJS: Implement Intl.NumberFormat V3's [[RoundingIncrement]] changes
2022-07-18 10:01:02 -04:00
break;
case PreferredResult::GreaterThanNumber:
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.number = result.number.plus(1);
LibJS: Implement Intl.NumberFormat V3's [[RoundingIncrement]] changes
2022-07-18 10:01:02 -04:00
break;
}
}
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.rounded = result.number.divided_by_power(fraction);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
return result;
}
LibJS: Reorganize spec steps for Intl.NumberFormat This is an editorial change in the Intl spec: https://github.com/tc39/ecma402/commit/110cb1f
2022-03-15 10:58:47 -04:00
// 15.5.9 ToRawFixed ( x, minInteger, minFraction, maxFraction ), https://tc39.es/ecma402/#sec-torawfixed
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 1.1.11 ToRawFixed ( x, minFraction, maxFraction, roundingIncrement, unsignedRoundingMode ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-torawfixed
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
RawFormatResult to_raw_fixed(MathematicalValue const& number, int min_fraction, int max_fraction, int rounding_increment, Optional<NumberFormat::UnsignedRoundingMode> const& unsigned_rounding_mode)
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
{
RawFormatResult result {};
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 1. Let f be maxFraction.
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
int fraction = max_fraction;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 2. Let n1 be an integer and r1 a mathematical value, with r1 = ToRawFixedFn(n1, f), such that n1 modulo roundingIncrement = 0, r1 ≤ x, and r1 is maximized.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto [number1, rounded1] = to_raw_fixed_function(number, fraction, rounding_increment, PreferredResult::LessThanNumber);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 3. Let n2 be an integer and r2 a mathematical value, with r2 = ToRawFixedFn(n2, f), such that n2 modulo roundingIncrement = 0, r2 ≥ x, and r2 is minimized.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto [number2, rounded2] = to_raw_fixed_function(number, fraction, rounding_increment, PreferredResult::GreaterThanNumber);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 4. Let r be ApplyUnsignedRoundingMode(x, r1, r2, unsignedRoundingMode).
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto rounded = apply_unsigned_rounding_mode(number, rounded1, rounded2, unsigned_rounding_mode);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
MathematicalValue n;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 5. If r is r1, then
LibJS: Return an enum from ApplyUnsignedRoundingMode 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.
2022-07-19 12:27:54 -04:00
if (rounded == RoundingDecision::LowerValue) {
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// a. Let n be n1.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
n = move(number1);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// b. Let xFinal be r1.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.rounded_number = move(rounded1);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
}
// 6. Else,
else {
// a. Let n be n2.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
n = move(number2);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// b. Let xFinal be r2.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.rounded_number = move(rounded2);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
}
// 7. If n = 0, let m be "0". Otherwise, let m be the String consisting of the digits of the decimal representation of n (in order, with no leading zeroes).
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
result.formatted_string = n.is_zero() ? String("0"sv) : n.to_string();
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 8. If f ≠ 0, then
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
if (fraction != 0) {
// a. Let k be the number of characters in m.
auto decimals = result.formatted_string.length();
// b. If k ≤ f, then
if (decimals <= static_cast<size_t>(fraction)) {
// i. Let z be the String value consisting of f+1–k occurrences of the character "0".
auto zeroes = String::repeated('0', fraction + 1 - decimals);
// ii. Let m be the string-concatenation of z and m.
result.formatted_string = String::formatted("{}{}", zeroes, result.formatted_string);
// iii. Let k be f+1.
decimals = fraction + 1;
}
// c. Let a be the first k–f characters of m, and let b be the remaining f characters of m.
auto a = result.formatted_string.substring_view(0, decimals - fraction);
auto b = result.formatted_string.substring_view(decimals - fraction, fraction);
// d. Let m be the string-concatenation of a, ".", and b.
result.formatted_string = String::formatted("{}.{}", a, b);
// e. Let int be the number of characters in a.
result.digits = a.length();
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 9. Else, let int be the number of characters in m.
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
else {
result.digits = result.formatted_string.length();
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 10. Let cut be maxFraction – minFraction.
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
int cut = max_fraction - min_fraction;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// Steps 11-12 are implemented by cut_trailing_zeroes.
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
result.formatted_string = cut_trailing_zeroes(result.formatted_string, cut);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 13. Return the Record { [[FormattedString]]: m, [[RoundedNumber]]: xFinal, [[IntegerDigitsCount]]: int, [[RoundingMagnitude]]: –f }.
LibJS: Implement Intl.NumberFormat V3's [[RoundingPriority]] changes
2022-07-16 12:11:20 -04:00
result.rounding_magnitude = -fraction;
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
return result;
}
LibJS: Reorganize spec steps for Intl.NumberFormat This is an editorial change in the Intl spec: https://github.com/tc39/ecma402/commit/110cb1f
2022-03-15 10:58:47 -04:00
// 15.5.11 GetNumberFormatPattern ( numberFormat, x ), https://tc39.es/ecma402/#sec-getnumberformatpattern
LibJS: Implement Intl.NumberFormat V3's [[SignDisplay]] changes Intl.NumberFormat V3 adds a "negative" option for [[SignDisplay]] to only use the locale's signed pattern for negative numbers.
2022-07-12 15:07:52 -04:00
// 1.1.14 GetNumberFormatPattern ( numberFormat, x ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-getnumberformatpattern
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
Optional<Variant<StringView, String>> get_number_format_pattern(VM& vm, NumberFormat& number_format, MathematicalValue const& number, Unicode::NumberFormat& found_pattern)
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
{
// 1. Let localeData be %NumberFormat%.[[LocaleData]].
// 2. Let dataLocale be numberFormat.[[DataLocale]].
// 3. Let dataLocaleData be localeData.[[<dataLocale>]].
// 4. Let patterns be dataLocaleData.[[patterns]].
// 5. Assert: patterns is a Record (see 15.3.3).
Optional<Unicode::NumberFormat> patterns;
// 6. Let style be numberFormat.[[Style]].
switch (number_format.style()) {
// 7. If style is "percent", then
case NumberFormat::Style::Percent:
// a. Let patterns be patterns.[[percent]].
patterns = Unicode::get_standard_number_system_format(number_format.data_locale(), number_format.numbering_system(), Unicode::StandardNumberFormatType::Percent);
break;
// 8. Else if style is "unit", then
LibJS: Implement unit number formatting
2021-11-16 13:56:52 -05:00
case NumberFormat::Style::Unit: {
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// a. Let unit be numberFormat.[[Unit]].
// b. Let unitDisplay be numberFormat.[[UnitDisplay]].
// c. Let patterns be patterns.[[unit]].
// d. If patterns doesn't have a field [[<unit>]], then
// i. Let unit be "fallback".
// e. Let patterns be patterns.[[<unit>]].
// f. Let patterns be patterns.[[<unitDisplay>]].
LibJS: Convert Intl.NumberFormat to use Unicode::Style
2022-01-25 11:49:11 -05:00
auto formats = Unicode::get_unit_formats(number_format.data_locale(), number_format.unit(), number_format.unit_display());
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
auto plurality = resolve_plural(number_format, Unicode::PluralForm::Cardinal, number.to_value(vm));
LibJS: Use Intl.PluralRules within Intl.NumberFormat 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.
2022-07-08 12:05:09 -04:00
if (auto it = formats.find_if([&](auto& p) { return p.plurality == plurality; }); it != formats.end())
patterns = move(*it);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
break;
LibJS: Implement unit number formatting
2021-11-16 13:56:52 -05:00
}
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 9. Else if style is "currency", then
case NumberFormat::Style::Currency:
// a. Let currency be numberFormat.[[Currency]].
// b. Let currencyDisplay be numberFormat.[[CurrencyDisplay]].
// c. Let currencySign be numberFormat.[[CurrencySign]].
// d. Let patterns be patterns.[[currency]].
// e. If patterns doesn't have a field [[<currency>]], then
// i. Let currency be "fallback".
// f. Let patterns be patterns.[[<currency>]].
// g. Let patterns be patterns.[[<currencyDisplay>]].
// h. Let patterns be patterns.[[<currencySign>]].
LibJS+LibUnicode: Fully implement currency number formatting Currencies are a bit strange; the layout of currency data in the CLDR is not particularly compatible with what ECMA-402 expects. For example, the currency format in the "en" and "ar" locales for the Latin script are: en: "¤#,##0.00" ar: "¤\u00A0#,##0.00" Note how the "ar" locale has a non-breaking space after the currency symbol (¤), but "en" does not. This does not mean that this space will appear in the "ar"-formatted string, nor does it mean that a space won't appear in the "en"-formatted string. This is a runtime decision based on the currency display chosen by the user ("$" vs. "USD" vs. "US dollar") and other rules in the Unicode TR-35 spec. ECMA-402 shies away from the nuances here with "implementation-defined" steps. LibUnicode will store the data parsed from the CLDR however it is presented; making decisions about spacing, etc. will occur at runtime based on user input.
2021-11-12 23:16:37 -05:00
// Handling of other [[CurrencyDisplay]] options will occur after [[SignDisplay]].
if (number_format.currency_display() == NumberFormat::CurrencyDisplay::Name) {
LibJS+LibUnicode: Rename method to select a NumberFormat plurality Instead of currency pattern lookups within select_currency_unit_pattern, rename the method to select_pattern_with_plurality and accept any list of patterns. This method will be needed for units.
2021-11-16 09:45:27 -05:00
auto formats = Unicode::get_compact_number_system_formats(number_format.data_locale(), number_format.numbering_system(), Unicode::CompactNumberFormatType::CurrencyUnit);
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
auto plurality = resolve_plural(number_format, Unicode::PluralForm::Cardinal, number.to_value(vm));
LibJS+LibUnicode: Rename method to select a NumberFormat plurality Instead of currency pattern lookups within select_currency_unit_pattern, rename the method to select_pattern_with_plurality and accept any list of patterns. This method will be needed for units.
2021-11-16 09:45:27 -05:00
LibJS: Use Intl.PluralRules within Intl.NumberFormat 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.
2022-07-08 12:05:09 -04:00
if (auto it = formats.find_if([&](auto& p) { return p.plurality == plurality; }); it != formats.end()) {
patterns = move(*it);
LibJS+LibUnicode: Fully implement currency number formatting Currencies are a bit strange; the layout of currency data in the CLDR is not particularly compatible with what ECMA-402 expects. For example, the currency format in the "en" and "ar" locales for the Latin script are: en: "¤#,##0.00" ar: "¤\u00A0#,##0.00" Note how the "ar" locale has a non-breaking space after the currency symbol (¤), but "en" does not. This does not mean that this space will appear in the "ar"-formatted string, nor does it mean that a space won't appear in the "en"-formatted string. This is a runtime decision based on the currency display chosen by the user ("$" vs. "USD" vs. "US dollar") and other rules in the Unicode TR-35 spec. ECMA-402 shies away from the nuances here with "implementation-defined" steps. LibUnicode will store the data parsed from the CLDR however it is presented; making decisions about spacing, etc. will occur at runtime based on user input.
2021-11-12 23:16:37 -05:00
break;
}
}
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
switch (number_format.currency_sign()) {
case NumberFormat::CurrencySign::Standard:
patterns = Unicode::get_standard_number_system_format(number_format.data_locale(), number_format.numbering_system(), Unicode::StandardNumberFormatType::Currency);
break;
case NumberFormat::CurrencySign::Accounting:
patterns = Unicode::get_standard_number_system_format(number_format.data_locale(), number_format.numbering_system(), Unicode::StandardNumberFormatType::Accounting);
break;
}
break;
// 10. Else,
case NumberFormat::Style::Decimal:
// a. Assert: style is "decimal".
// b. Let patterns be patterns.[[decimal]].
patterns = Unicode::get_standard_number_system_format(number_format.data_locale(), number_format.numbering_system(), Unicode::StandardNumberFormatType::Decimal);
break;
default:
VERIFY_NOT_REACHED();
}
if (!patterns.has_value())
return {};
StringView pattern;
// 11. Let signDisplay be numberFormat.[[SignDisplay]].
switch (number_format.sign_display()) {
// 12. If signDisplay is "never", then
case NumberFormat::SignDisplay::Never:
// a. Let pattern be patterns.[[zeroPattern]].
pattern = patterns->zero_format;
break;
// 13. Else if signDisplay is "auto", then
case NumberFormat::SignDisplay::Auto:
// a. If x is 0 or x > 0 or x is NaN, then
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if (number.is_zero() || number.is_positive() || number.is_nan()) {
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// i. Let pattern be patterns.[[zeroPattern]].
pattern = patterns->zero_format;
}
// b. Else,
else {
// i. Let pattern be patterns.[[negativePattern]].
pattern = patterns->negative_format;
}
break;
// 14. Else if signDisplay is "always", then
case NumberFormat::SignDisplay::Always:
// a. If x is 0 or x > 0 or x is NaN, then
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if (number.is_zero() || number.is_positive() || number.is_nan()) {
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// i. Let pattern be patterns.[[positivePattern]].
pattern = patterns->positive_format;
}
// b. Else,
else {
// i. Let pattern be patterns.[[negativePattern]].
pattern = patterns->negative_format;
}
break;
LibJS: Implement Intl.NumberFormat V3's [[SignDisplay]] changes Intl.NumberFormat V3 adds a "negative" option for [[SignDisplay]] to only use the locale's signed pattern for negative numbers.
2022-07-12 15:07:52 -04:00
// 15. Else if signDisplay is "exceptZero", then
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
case NumberFormat::SignDisplay::ExceptZero:
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// a. If x is 0 or x is -0 or x is NaN, then
if (number.is_zero() || number.is_negative_zero() || number.is_nan()) {
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// i. Let pattern be patterns.[[zeroPattern]].
pattern = patterns->zero_format;
}
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// b. Else if x > 0, then
else if (number.is_positive()) {
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// i. Let pattern be patterns.[[positivePattern]].
pattern = patterns->positive_format;
}
LibJS: Implement Intl.NumberFormat V3's [[SignDisplay]] changes Intl.NumberFormat V3 adds a "negative" option for [[SignDisplay]] to only use the locale's signed pattern for negative numbers.
2022-07-12 15:07:52 -04:00
// c. Else,
else {
// i. Let pattern be patterns.[[negativePattern]].
pattern = patterns->negative_format;
}
break;
// 16. Else,
case NumberFormat::SignDisplay::Negative:
// a. Assert: signDisplay is "negative".
// b. If x is 0 or x is -0 or x > 0 or x is NaN, then
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if (number.is_zero() || number.is_negative_zero() || number.is_positive() || number.is_nan()) {
LibJS: Implement Intl.NumberFormat V3's [[SignDisplay]] changes Intl.NumberFormat V3 adds a "negative" option for [[SignDisplay]] to only use the locale's signed pattern for negative numbers.
2022-07-12 15:07:52 -04:00
// i. Let pattern be patterns.[[zeroPattern]].
pattern = patterns->zero_format;
}
// c. Else,
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
else {
// i. Let pattern be patterns.[[negativePattern]].
pattern = patterns->negative_format;
}
break;
default:
LibJS: Implement Intl.NumberFormat V3's [[SignDisplay]] changes Intl.NumberFormat V3 adds a "negative" option for [[SignDisplay]] to only use the locale's signed pattern for negative numbers.
2022-07-12 15:07:52 -04:00
VERIFY_NOT_REACHED();
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
LibJS: Implement unit number formatting
2021-11-16 13:56:52 -05:00
found_pattern = patterns.release_value();
LibJS+LibUnicode: Fully implement currency number formatting Currencies are a bit strange; the layout of currency data in the CLDR is not particularly compatible with what ECMA-402 expects. For example, the currency format in the "en" and "ar" locales for the Latin script are: en: "¤#,##0.00" ar: "¤\u00A0#,##0.00" Note how the "ar" locale has a non-breaking space after the currency symbol (¤), but "en" does not. This does not mean that this space will appear in the "ar"-formatted string, nor does it mean that a space won't appear in the "en"-formatted string. This is a runtime decision based on the currency display chosen by the user ("$" vs. "USD" vs. "US dollar") and other rules in the Unicode TR-35 spec. ECMA-402 shies away from the nuances here with "implementation-defined" steps. LibUnicode will store the data parsed from the CLDR however it is presented; making decisions about spacing, etc. will occur at runtime based on user input.
2021-11-12 23:16:37 -05:00
// Handling of steps 9b/9g: Depending on the currency display and the format pattern found above,
// we might need to mutate the format pattern to inject a space between the currency display and
// the currency number.
if (number_format.style() == NumberFormat::Style::Currency) {
LibJS+LibUnicode: Don't remove {currency} keys in GetNumberFormatPattern In order to implement Intl.NumberFormat.prototype.formatToParts, do not replace {currency} keys in the format pattern before ECMA-402 tells us to. Otherwise, the array return by formatToParts will not contain the expected currency key. Early replacement was done to avoid resolving the currency display more than once, as it involves a couple of round trips to search through LibUnicode data. So this adds a non-standard method to NumberFormat to do this resolution and cache the result. Another side effect of this change is that LibUnicode must replace unit format patterns of the form "{0} {1}" during code generation. These were previously skipped during code generation because LibJS would just replace the keys with the currency display at runtime. But now that the currency display injection is delayed, any {0} or {1} keys in the format pattern will cause PartitionNumberPattern to abort.
2021-11-13 10:15:33 -05:00
auto modified_pattern = Unicode::augment_currency_format_pattern(number_format.resolve_currency_display(), pattern);
if (modified_pattern.has_value())
return modified_pattern.release_value();
LibJS+LibUnicode: Fully implement currency number formatting Currencies are a bit strange; the layout of currency data in the CLDR is not particularly compatible with what ECMA-402 expects. For example, the currency format in the "en" and "ar" locales for the Latin script are: en: "¤#,##0.00" ar: "¤\u00A0#,##0.00" Note how the "ar" locale has a non-breaking space after the currency symbol (¤), but "en" does not. This does not mean that this space will appear in the "ar"-formatted string, nor does it mean that a space won't appear in the "en"-formatted string. This is a runtime decision based on the currency display chosen by the user ("$" vs. "USD" vs. "US dollar") and other rules in the Unicode TR-35 spec. ECMA-402 shies away from the nuances here with "implementation-defined" steps. LibUnicode will store the data parsed from the CLDR however it is presented; making decisions about spacing, etc. will occur at runtime based on user input.
2021-11-12 23:16:37 -05:00
}
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 16. Return pattern.
return pattern;
}
LibJS: Reorganize spec steps for Intl.NumberFormat This is an editorial change in the Intl spec: https://github.com/tc39/ecma402/commit/110cb1f
2022-03-15 10:58:47 -04:00
// 15.5.12 GetNotationSubPattern ( numberFormat, exponent ), https://tc39.es/ecma402/#sec-getnotationsubpattern
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
Optional<StringView> get_notation_sub_pattern(NumberFormat& number_format, int exponent)
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
{
// 1. Let localeData be %NumberFormat%.[[LocaleData]].
// 2. Let dataLocale be numberFormat.[[DataLocale]].
// 3. Let dataLocaleData be localeData.[[<dataLocale>]].
// 4. Let notationSubPatterns be dataLocaleData.[[notationSubPatterns]].
// 5. Assert: notationSubPatterns is a Record (see 15.3.3).
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 6. Let notation be numberFormat.[[Notation]].
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
auto notation = number_format.notation();
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 7. If notation is "scientific" or notation is "engineering", then
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
if ((notation == NumberFormat::Notation::Scientific) || (notation == NumberFormat::Notation::Engineering)) {
// a. Return notationSubPatterns.[[scientific]].
auto notation_sub_patterns = Unicode::get_standard_number_system_format(number_format.data_locale(), number_format.numbering_system(), Unicode::StandardNumberFormatType::Scientific);
if (!notation_sub_patterns.has_value())
return {};
return notation_sub_patterns->zero_format;
}
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 8. Else if exponent is not 0, then
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
else if (exponent != 0) {
// a. Assert: notation is "compact".
LibJS: Implement compact formatting for Intl.NumberFormat
2021-11-15 11:07:41 -05:00
VERIFY(notation == NumberFormat::Notation::Compact);
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
// b. Let compactDisplay be numberFormat.[[CompactDisplay]].
// c. Let compactPatterns be notationSubPatterns.[[compact]].[[<compactDisplay>]].
// d. Return compactPatterns.[[<exponent>]].
LibJS: Implement compact formatting for Intl.NumberFormat
2021-11-15 11:07:41 -05:00
if (number_format.has_compact_format())
return number_format.compact_format().zero_format;
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
}
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 9. Else,
// a. Return "{number}".
return "{number}"sv;
}
LibJS: Reorganize spec steps for Intl.NumberFormat This is an editorial change in the Intl spec: https://github.com/tc39/ecma402/commit/110cb1f
2022-03-15 10:58:47 -04:00
// 15.5.13 ComputeExponent ( numberFormat, x ), https://tc39.es/ecma402/#sec-computeexponent
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
int compute_exponent(NumberFormat& number_format, MathematicalValue number)
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
{
// 1. If x = 0, then
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if (number.is_zero()) {
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// a. Return 0.
return 0;
}
// 2. If x < 0, then
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if (number.is_negative()) {
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// a. Let x = -x.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
number.negate();
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
// 3. Let magnitude be the base 10 logarithm of x rounded down to the nearest integer.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
int magnitude = number.logarithmic_floor();
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 4. Let exponent be ComputeExponentForMagnitude(numberFormat, magnitude).
Everywhere: Fix spelling mistakes
2022-01-07 05:04:05 -07:00
int exponent = compute_exponent_for_magnitude(number_format, magnitude);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 5. Let x be x × 10^(-exponent).
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
number = number.multiplied_by_power(-exponent);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 6. Let formatNumberResult be FormatNumericToString(numberFormat, x).
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto format_number_result = format_numeric_to_string(number_format, move(number));
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 7. If formatNumberResult.[[RoundedNumber]] = 0, then
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if (format_number_result.rounded_number.is_zero()) {
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// a. Return exponent.
return exponent;
}
// 8. Let newMagnitude be the base 10 logarithm of formatNumberResult.[[RoundedNumber]] rounded down to the nearest integer.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
int new_magnitude = format_number_result.rounded_number.logarithmic_floor();
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
// 9. If newMagnitude is magnitude – exponent, then
if (new_magnitude == magnitude - exponent) {
// a. Return exponent.
return exponent;
}
// 10. Return ComputeExponentForMagnitude(numberFormat, magnitude + 1).
Everywhere: Fix spelling mistakes
2022-01-07 05:04:05 -07:00
return compute_exponent_for_magnitude(number_format, magnitude + 1);
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
LibJS: Reorganize spec steps for Intl.NumberFormat This is an editorial change in the Intl spec: https://github.com/tc39/ecma402/commit/110cb1f
2022-03-15 10:58:47 -04:00
// 15.5.14 ComputeExponentForMagnitude ( numberFormat, magnitude ), https://tc39.es/ecma402/#sec-computeexponentformagnitude
Everywhere: Fix spelling mistakes
2022-01-07 05:04:05 -07:00
int compute_exponent_for_magnitude(NumberFormat& number_format, int magnitude)
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
{
// 1. Let notation be numberFormat.[[Notation]].
switch (number_format.notation()) {
// 2. If notation is "standard", then
case NumberFormat::Notation::Standard:
// a. Return 0.
return 0;
// 3. Else if notation is "scientific", then
case NumberFormat::Notation::Scientific:
// a. Return magnitude.
return magnitude;
// 4. Else if notation is "engineering", then
case NumberFormat::Notation::Engineering: {
// a. Let thousands be the greatest integer that is not greater than magnitude / 3.
double thousands = floor(static_cast<double>(magnitude) / 3.0);
// b. Return thousands × 3.
return static_cast<int>(thousands) * 3;
}
// 5. Else,
case NumberFormat::Notation::Compact: {
// a. Assert: notation is "compact".
VERIFY(number_format.has_compact_display());
// b. Let exponent be an implementation- and locale-dependent (ILD) integer by which to scale a number of the given magnitude in compact notation for the current locale.
// c. Return exponent.
Vector<Unicode::NumberFormat> format_rules;
if (number_format.style() == NumberFormat::Style::Currency)
format_rules = Unicode::get_compact_number_system_formats(number_format.data_locale(), number_format.numbering_system(), Unicode::CompactNumberFormatType::CurrencyShort);
else if (number_format.compact_display() == NumberFormat::CompactDisplay::Long)
format_rules = Unicode::get_compact_number_system_formats(number_format.data_locale(), number_format.numbering_system(), Unicode::CompactNumberFormatType::DecimalLong);
else
format_rules = Unicode::get_compact_number_system_formats(number_format.data_locale(), number_format.numbering_system(), Unicode::CompactNumberFormatType::DecimalShort);
Unicode::NumberFormat const* best_number_format = nullptr;
for (auto const& format_rule : format_rules) {
if (format_rule.magnitude > magnitude)
break;
best_number_format = &format_rule;
}
LibJS: Cache the number format used for compact notation Finding the best number format to use for compact notation involves creating a Vector of all compact formats for the locale and looking for the one that best matches the number's magnitude. ECMA-402 wants this number format to be found multiple times, so cache the result for future use.
2021-11-15 08:26:55 -05:00
if (best_number_format == nullptr)
return 0;
number_format.set_compact_format(*best_number_format);
return best_number_format->exponent;
LibJS: Begin implementing Intl.NumberFormat.prototype.format There is quite a lot to be done here so this is just a first pass at number formatting. Decimal and percent formatting are mostly working, but only for standard and compact notation (engineering and scientific notation are not implemented here). Currency formatting is parsed, but there is more work to be done to handle e.g. using symbols instead of currency codes ("$" instead of "USD"), and putting spaces around the currency symbol ("USD 2.00" instead of "USD2.00").
2021-11-10 12:34:14 -05:00
}
default:
VERIFY_NOT_REACHED();
}
}
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// 1.1.18 ToIntlMathematicalValue ( value ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-tointlmathematicalvalue
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
ThrowCompletionOr<MathematicalValue> to_intl_mathematical_value(VM& vm, Value value)
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
{
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// 1. Let primValue be ? ToPrimitive(value, number).
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto primitive_value = TRY(value.to_primitive(vm, Value::PreferredType::Number));
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// 2. If Type(primValue) is BigInt, return the mathematical value of primValue.
if (primitive_value.is_bigint())
return primitive_value.as_bigint().big_integer();
// FIXME: The remaining steps are being refactored into a new Runtime Semantic, StringIntlMV.
// We short-circuit some of these steps to avoid known pitfalls.
// See: https://github.com/tc39/proposal-intl-numberformat-v3/pull/82
if (!primitive_value.is_string()) {
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto number = TRY(primitive_value.to_number(vm));
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
return number.as_double();
}
// 3. If Type(primValue) is String,
// a. Let str be primValue.
auto const& string = primitive_value.as_string().string();
// Step 4 handled separately by the FIXME above.
// 5. If the grammar cannot interpret str as an expansion of StringNumericLiteral, return not-a-number.
// 6. Let mv be the MV, a mathematical value, of ? ToNumber(str), as described in 7.1.4.1.1.
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto mathematical_value = TRY(primitive_value.to_number(vm)).as_double();
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
// 7. If mv is 0 and the first non white space code point in str is -, return negative-zero.
if (mathematical_value == 0.0 && string.view().trim_whitespace(TrimMode::Left).starts_with('-'))
return MathematicalValue::Symbol::NegativeZero;
// 8. If mv is 10^10000 and str contains Infinity, return positive-infinity.
if (mathematical_value == pow(10, 10000) && string.contains("Infinity"sv))
return MathematicalValue::Symbol::PositiveInfinity;
// 9. If mv is -10^10000 and str contains Infinity, return negative-infinity.
if (mathematical_value == pow(-10, 10000) && string.contains("Infinity"sv))
return MathematicalValue::Symbol::NegativeInfinity;
// 10. Return mv.
return mathematical_value;
}
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 1.1.19 GetUnsignedRoundingMode ( roundingMode, isNegative ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-getunsignedroundingmode
NumberFormat::UnsignedRoundingMode get_unsigned_rounding_mode(NumberFormat::RoundingMode rounding_mode, bool is_negative)
{
// 1. If isNegative is true, return the specification type in the third column of Table 2 where the first column is roundingMode and the second column is "negative".
// 2. Else, return the specification type in the third column of Table 2 where the first column is roundingMode and the second column is "positive".
// Table 2: Conversion from rounding mode to unsigned rounding mode, https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#table-intl-unsigned-rounding-modes
switch (rounding_mode) {
case NumberFormat::RoundingMode::Ceil:
return is_negative ? NumberFormat::UnsignedRoundingMode::Zero : NumberFormat::UnsignedRoundingMode::Infinity;
case NumberFormat::RoundingMode::Floor:
return is_negative ? NumberFormat::UnsignedRoundingMode::Infinity : NumberFormat::UnsignedRoundingMode::Zero;
case NumberFormat::RoundingMode::Expand:
return NumberFormat::UnsignedRoundingMode::Infinity;
case NumberFormat::RoundingMode::Trunc:
return NumberFormat::UnsignedRoundingMode::Zero;
case NumberFormat::RoundingMode::HalfCeil:
return is_negative ? NumberFormat::UnsignedRoundingMode::HalfZero : NumberFormat::UnsignedRoundingMode::HalfInfinity;
case NumberFormat::RoundingMode::HalfFloor:
return is_negative ? NumberFormat::UnsignedRoundingMode::HalfInfinity : NumberFormat::UnsignedRoundingMode::HalfZero;
case NumberFormat::RoundingMode::HalfExpand:
return NumberFormat::UnsignedRoundingMode::HalfInfinity;
case NumberFormat::RoundingMode::HalfTrunc:
return NumberFormat::UnsignedRoundingMode::HalfZero;
case NumberFormat::RoundingMode::HalfEven:
return NumberFormat::UnsignedRoundingMode::HalfEven;
default:
VERIFY_NOT_REACHED();
};
}
// 1.1.20 ApplyUnsignedRoundingMode ( x, r1, r2, unsignedRoundingMode ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-applyunsignedroundingmode
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
RoundingDecision apply_unsigned_rounding_mode(MathematicalValue const& x, MathematicalValue const& r1, MathematicalValue const& r2, Optional<NumberFormat::UnsignedRoundingMode> const& unsigned_rounding_mode)
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
{
// 1. If x is equal to r1, return r1.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if (x.is_equal_to(r1))
LibJS: Return an enum from ApplyUnsignedRoundingMode 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.
2022-07-19 12:27:54 -04:00
return RoundingDecision::LowerValue;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// FIXME: We skip this assertion due floating point inaccuracies. For example, entering "1.2345"
// in the JS REPL results in "1.234499999999999", and may cause this assertion to fail.
//
// This should be resolved when the "Intl mathematical value" is implemented to support
// arbitrarily precise decimals.
// https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#intl-mathematical-value
// 2. Assert: r1 < x < r2.
// 3. Assert: unsignedRoundingMode is not undefined.
VERIFY(unsigned_rounding_mode.has_value());
// 4. If unsignedRoundingMode is zero, return r1.
if (unsigned_rounding_mode == NumberFormat::UnsignedRoundingMode::Zero)
LibJS: Return an enum from ApplyUnsignedRoundingMode 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.
2022-07-19 12:27:54 -04:00
return RoundingDecision::LowerValue;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 5. If unsignedRoundingMode is infinity, return r2.
if (unsigned_rounding_mode == NumberFormat::UnsignedRoundingMode::Infinity)
LibJS: Return an enum from ApplyUnsignedRoundingMode 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.
2022-07-19 12:27:54 -04:00
return RoundingDecision::HigherValue;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 6. Let d1 be x – r1.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto d1 = x.minus(r1);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 7. Let d2 be r2 – x.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto d2 = r2.minus(x);
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 8. If d1 < d2, return r1.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if (d1.is_less_than(d2))
LibJS: Return an enum from ApplyUnsignedRoundingMode 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.
2022-07-19 12:27:54 -04:00
return RoundingDecision::LowerValue;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 9. If d2 < d1, return r2.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if (d2.is_less_than(d1))
LibJS: Return an enum from ApplyUnsignedRoundingMode 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.
2022-07-19 12:27:54 -04:00
return RoundingDecision::HigherValue;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 10. Assert: d1 is equal to d2.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
VERIFY(d1.is_equal_to(d2));
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 11. If unsignedRoundingMode is half-zero, return r1.
if (unsigned_rounding_mode == NumberFormat::UnsignedRoundingMode::HalfZero)
LibJS: Return an enum from ApplyUnsignedRoundingMode 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.
2022-07-19 12:27:54 -04:00
return RoundingDecision::LowerValue;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 12. If unsignedRoundingMode is half-infinity, return r2.
if (unsigned_rounding_mode == NumberFormat::UnsignedRoundingMode::HalfInfinity)
LibJS: Return an enum from ApplyUnsignedRoundingMode 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.
2022-07-19 12:27:54 -04:00
return RoundingDecision::HigherValue;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 13. Assert: unsignedRoundingMode is half-even.
VERIFY(unsigned_rounding_mode == NumberFormat::UnsignedRoundingMode::HalfEven);
// 14. Let cardinality be (r1 / (r2 – r1)) modulo 2.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
auto cardinality = r1.divided_by(r2.minus(r1));
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 15. If cardinality is 0, return r1.
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
if (cardinality.modulo_is_zero(2))
LibJS: Return an enum from ApplyUnsignedRoundingMode 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.
2022-07-19 12:27:54 -04:00
return RoundingDecision::LowerValue;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
// 16. Return r2.
LibJS: Return an enum from ApplyUnsignedRoundingMode 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.
2022-07-19 12:27:54 -04:00
return RoundingDecision::HigherValue;
LibJS: Implement Intl.NumberFormat V3's [[RoundingMode]] changes
2022-07-18 09:04:57 -04:00
}
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
// 1.1.21 PartitionNumberRangePattern ( numberFormat, x, y ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-partitionnumberrangepattern
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
ThrowCompletionOr<Vector<PatternPartitionWithSource>> partition_number_range_pattern(VM& vm, NumberFormat& number_format, MathematicalValue start, MathematicalValue end)
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
{
// 1. If x is NaN or y is NaN, throw a RangeError exception.
if (start.is_nan())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<RangeError>(ErrorType::IntlNumberIsNaN, "start"sv);
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
if (end.is_nan())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<RangeError>(ErrorType::IntlNumberIsNaN, "end"sv);
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
LibJS: Allow out-of-order number ranges to be formatted This is a normative change to the Intl NumberFormat V3 spec: https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
2022-07-26 06:55:25 -04:00
// 2. Let result be a new empty List.
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
Vector<PatternPartitionWithSource> result;
LibJS: Allow out-of-order number ranges to be formatted This is a normative change to the Intl NumberFormat V3 spec: https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
2022-07-26 06:55:25 -04:00
// 3. Let xResult be ? PartitionNumberPattern(numberFormat, x).
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
auto raw_start_result = partition_number_pattern(vm, number_format, move(start));
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
auto start_result = PatternPartitionWithSource::create_from_parent_list(move(raw_start_result));
LibJS: Allow out-of-order number ranges to be formatted This is a normative change to the Intl NumberFormat V3 spec: https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
2022-07-26 06:55:25 -04:00
// 4. Let yResult be ? PartitionNumberPattern(numberFormat, y).
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
auto raw_end_result = partition_number_pattern(vm, number_format, move(end));
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
auto end_result = PatternPartitionWithSource::create_from_parent_list(move(raw_end_result));
LibJS: Allow out-of-order number ranges to be formatted This is a normative change to the Intl NumberFormat V3 spec: https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
2022-07-26 06:55:25 -04:00
// 5. If xResult is equal to yResult, return FormatApproximately(numberFormat, xResult).
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
if (start_result == end_result)
return format_approximately(number_format, move(start_result));
LibJS: Allow out-of-order number ranges to be formatted This is a normative change to the Intl NumberFormat V3 spec: https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
2022-07-26 06:55:25 -04:00
// 6. For each r in xResult, do
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
for (auto& part : start_result) {
// i. Set r.[[Source]] to "startRange".
part.source = "startRange"sv;
}
LibJS: Allow out-of-order number ranges to be formatted This is a normative change to the Intl NumberFormat V3 spec: https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
2022-07-26 06:55:25 -04:00
// 7. Add all elements in xResult to result in order.
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
result = move(start_result);
LibJS: Allow out-of-order number ranges to be formatted This is a normative change to the Intl NumberFormat V3 spec: https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
2022-07-26 06:55:25 -04:00
// 8. Let rangeSeparator be an ILND String value used to separate two numbers.
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
auto range_separator_symbol = Unicode::get_number_system_symbol(number_format.data_locale(), number_format.numbering_system(), Unicode::NumericSymbol::RangeSeparator).value_or("-"sv);
auto range_separator = Unicode::augment_range_pattern(range_separator_symbol, result.last().value, end_result[0].value);
LibJS: Allow out-of-order number ranges to be formatted This is a normative change to the Intl NumberFormat V3 spec: https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
2022-07-26 06:55:25 -04:00
// 9. Append a new Record { [[Type]]: "literal", [[Value]]: rangeSeparator, [[Source]]: "shared" } element to result.
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
PatternPartitionWithSource part;
part.type = "literal"sv;
part.value = range_separator.value_or(range_separator_symbol);
part.source = "shared"sv;
result.append(move(part));
LibJS: Allow out-of-order number ranges to be formatted This is a normative change to the Intl NumberFormat V3 spec: https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
2022-07-26 06:55:25 -04:00
// 10. For each r in yResult, do
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
for (auto& part : end_result) {
// a. Set r.[[Source]] to "endRange".
part.source = "endRange"sv;
}
LibJS: Allow out-of-order number ranges to be formatted This is a normative change to the Intl NumberFormat V3 spec: https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
2022-07-26 06:55:25 -04:00
// 11. Add all elements in yResult to result in order.
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
result.extend(move(end_result));
LibJS: Allow out-of-order number ranges to be formatted This is a normative change to the Intl NumberFormat V3 spec: https://github.com/tc39/proposal-intl-numberformat-v3/commit/0c3d849
2022-07-26 06:55:25 -04:00
// 12. Return ! CollapseNumberRange(result).
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
return collapse_number_range(move(result));
}
// 1.1.22 FormatApproximately ( numberFormat, result ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-formatapproximately
Vector<PatternPartitionWithSource> format_approximately(NumberFormat& number_format, Vector<PatternPartitionWithSource> result)
{
// 1. Let i be an index into result, determined by an implementation-defined algorithm based on numberFormat and result.
// 2. Let approximatelySign be an ILND String value used to signify that a number is approximate.
auto approximately_sign = Unicode::get_number_system_symbol(number_format.data_locale(), number_format.numbering_system(), Unicode::NumericSymbol::ApproximatelySign).value_or("~"sv);
// 3. Insert a new Record { [[Type]]: "approximatelySign", [[Value]]: approximatelySign } at index i in result.
PatternPartitionWithSource partition;
partition.type = "approximatelySign"sv;
partition.value = approximately_sign;
result.insert_before_matching(move(partition), [](auto const& part) {
return part.type.is_one_of("integer"sv, "decimal"sv, "plusSign"sv, "minusSign"sv, "percentSign"sv, "currency"sv);
});
// 4. Return result.
return result;
}
// 1.1.23 CollapseNumberRange ( result ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-collapsenumberrange
Vector<PatternPartitionWithSource> collapse_number_range(Vector<PatternPartitionWithSource> result)
{
// Returning result unmodified is guaranteed to be a correct implementation of CollapseNumberRange.
return result;
}
// 1.1.24 FormatNumericRange( numberFormat, x, y ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-formatnumericrange
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
ThrowCompletionOr<String> format_numeric_range(VM& vm, NumberFormat& number_format, MathematicalValue start, MathematicalValue end)
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
{
// 1. Let parts be ? PartitionNumberRangePattern(numberFormat, x, y).
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
auto parts = TRY(partition_number_range_pattern(vm, number_format, move(start), move(end)));
LibJS: Implement Intl.NumberFormat.prototype.formatRange
2022-07-20 15:08:01 -04:00
// 2. Let result be the empty String.
StringBuilder result;
// 3. For each part in parts, do
for (auto& part : parts) {
// a. Set result to the string-concatenation of result and part.[[Value]].
result.append(move(part.value));
}
// 4. Return result.
return result.build();
}
LibJS: Implement Intl.NumberFormat.prototype.formatRangeToParts
2022-07-20 15:29:00 -04:00
// 1.1.25 FormatNumericRangeToParts( numberFormat, x, y ), https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/proposed.html#sec-formatnumericrangetoparts
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
ThrowCompletionOr<Array*> format_numeric_range_to_parts(VM& vm, NumberFormat& number_format, MathematicalValue start, MathematicalValue end)
LibJS: Implement Intl.NumberFormat.prototype.formatRangeToParts
2022-07-20 15:29:00 -04:00
{
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
auto& realm = *vm.current_realm();
LibJS: Implement Intl.NumberFormat.prototype.formatRangeToParts
2022-07-20 15:29:00 -04:00
// 1. Let parts be ? PartitionNumberRangePattern(numberFormat, x, y).
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
auto parts = TRY(partition_number_range_pattern(vm, number_format, move(start), move(end)));
LibJS: Implement Intl.NumberFormat.prototype.formatRangeToParts
2022-07-20 15:29:00 -04:00
// 2. Let result be ! ArrayCreate(0).
LibJS+LibWeb: Replace GlobalObject with Realm in create() functions This is a continuation of the previous two commits. As allocating a JS cell already primarily involves a realm instead of a global object, and we'll need to pass one to the allocate() function itself eventually (it's bridged via the global object right now), the create() functions need to receive a realm as well. The plan is for this to be the highest-level function that actually receives a realm and passes it around, AOs on an even higher level will use the "current realm" concept via VM::current_realm() as that's what the spec assumes; passing around realms (or global objects, for that matter) on higher AO levels is pointless and unlike for allocating individual objects, which may happen outside of regular JS execution, we don't need control over the specific realm that is being used there.
2022-08-16 00:20:49 +01:00
auto* result = MUST(Array::create(realm, 0));
LibJS: Implement Intl.NumberFormat.prototype.formatRangeToParts
2022-07-20 15:29:00 -04:00
// 3. Let n be 0.
size_t n = 0;
// 4. For each Record { [[Type]], [[Value]] } part in parts, do
for (auto& part : parts) {
// a. Let O be OrdinaryObjectCreate(%Object.prototype%).
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
auto* object = Object::create(realm, realm.intrinsics().object_prototype());
LibJS: Implement Intl.NumberFormat.prototype.formatRangeToParts
2022-07-20 15:29:00 -04:00
// b. Perform ! CreateDataPropertyOrThrow(O, "type", part.[[Type]]).
MUST(object->create_data_property_or_throw(vm.names.type, js_string(vm, part.type)));
// c. Perform ! CreateDataPropertyOrThrow(O, "value", part.[[Value]]).
MUST(object->create_data_property_or_throw(vm.names.value, js_string(vm, move(part.value))));
// d. Perform ! CreateDataPropertyOrThrow(O, "source", part.[[Source]]).
MUST(object->create_data_property_or_throw(vm.names.source, js_string(vm, part.source)));
// e. Perform ! CreateDataPropertyOrThrow(result, ! ToString(n), O).
MUST(result->create_data_property_or_throw(n, object));
// f. Increment n by 1.
++n;
}
// 5. Return result.
return result;
}
LibJS: Implement a nearly empty Intl.NumberFormat object This adds plumbing for the Intl.NumberFormat object, constructor, and prototype.
2021-09-08 21:34:27 -04:00
}
Reference in a new issue Copy permalink