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

1523 lines
62 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: 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.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;
}
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();
}
Value NumberFormat::use_grouping_to_value(GlobalObject& global_object) const
{
auto& vm = global_object.vm();
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: 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
static ALWAYS_INLINE int log10floor(Value 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: 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_number())
return static_cast<int>(floor(log10(number.as_double())));
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
// FIXME: Can we do this without string conversion?
auto as_string = number.as_bigint().big_integer().to_base(10);
return as_string.length() - 1;
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
}
LibJS: Prevent i64 overflow when computing large NumberFormat exponents The largest exponents we compute are on the order of 10^21 (governed by the maximumSignificantDigits option, which has a max value of 21). That is too large to fit into the i64 we were using when multiplying this exponent by the value to be formatted. Instead, split up the logic to multiply that value by this exponent based on the value's underlying type: Number: Do not cast the result of pow() to an i64, and perform the follow-up multiplication with doubles. BigInt: Do not use pow(). Instead, compute the exponent as a BigInt from the start, then perform the follow-up multiplication with that BigInt.
2022-07-16 11:39:11 -04:00
static Value multiply(GlobalObject& global_object, Value lhs, i8 rhs)
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 (lhs.is_number())
return Value(lhs.as_double() * rhs);
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
auto rhs_bigint = Crypto::SignedBigInteger::create_from(rhs);
return js_bigint(global_object.vm(), lhs.as_bigint().big_integer().multiplied_by(rhs_bigint));
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
}
LibJS: Prevent i64 overflow when computing large NumberFormat exponents The largest exponents we compute are on the order of 10^21 (governed by the maximumSignificantDigits option, which has a max value of 21). That is too large to fit into the i64 we were using when multiplying this exponent by the value to be formatted. Instead, split up the logic to multiply that value by this exponent based on the value's underlying type: Number: Do not cast the result of pow() to an i64, and perform the follow-up multiplication with doubles. BigInt: Do not use pow(). Instead, compute the exponent as a BigInt from the start, then perform the follow-up multiplication with that BigInt.
2022-07-16 11:39:11 -04:00
static Value divide(GlobalObject& global_object, Value lhs, i8 rhs)
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 (lhs.is_number())
return Value(lhs.as_double() / rhs);
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
auto rhs_bigint = Crypto::SignedBigInteger::create_from(rhs);
return js_bigint(global_object.vm(), lhs.as_bigint().big_integer().divided_by(rhs_bigint).quotient);
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
}
LibJS: Prevent i64 overflow when computing large NumberFormat exponents The largest exponents we compute are on the order of 10^21 (governed by the maximumSignificantDigits option, which has a max value of 21). That is too large to fit into the i64 we were using when multiplying this exponent by the value to be formatted. Instead, split up the logic to multiply that value by this exponent based on the value's underlying type: Number: Do not cast the result of pow() to an i64, and perform the follow-up multiplication with doubles. BigInt: Do not use pow(). Instead, compute the exponent as a BigInt from the start, then perform the follow-up multiplication with that BigInt.
2022-07-16 11:39:11 -04:00
static Crypto::SignedBigInteger bigint_power(i8 base, i8 exponent)
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
{
LibJS: Prevent i64 overflow when computing large NumberFormat exponents The largest exponents we compute are on the order of 10^21 (governed by the maximumSignificantDigits option, which has a max value of 21). That is too large to fit into the i64 we were using when multiplying this exponent by the value to be formatted. Instead, split up the logic to multiply that value by this exponent based on the value's underlying type: Number: Do not cast the result of pow() to an i64, and perform the follow-up multiplication with doubles. BigInt: Do not use pow(). Instead, compute the exponent as a BigInt from the start, then perform the follow-up multiplication with that BigInt.
2022-07-16 11:39:11 -04:00
VERIFY(exponent >= 0);
auto base_bigint = Crypto::SignedBigInteger::create_from(base);
auto result = Crypto::SignedBigInteger::create_from(1);
for (i8 i = 0; i < exponent; ++i)
result = result.multiplied_by(base_bigint);
return result;
}
static ALWAYS_INLINE Value multiply_by_power(GlobalObject& global_object, Value number, i8 exponent)
{
if (number.is_number())
return Value(number.as_double() * pow(10, exponent));
if (exponent < 0) {
auto exponent_bigint = bigint_power(10, -exponent);
return js_bigint(global_object.vm(), number.as_bigint().big_integer().divided_by(exponent_bigint).quotient);
}
auto exponent_bigint = bigint_power(10, exponent);
return js_bigint(global_object.vm(), number.as_bigint().big_integer().multiplied_by(exponent_bigint));
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
}
LibJS: Prevent i64 overflow when computing large NumberFormat exponents The largest exponents we compute are on the order of 10^21 (governed by the maximumSignificantDigits option, which has a max value of 21). That is too large to fit into the i64 we were using when multiplying this exponent by the value to be formatted. Instead, split up the logic to multiply that value by this exponent based on the value's underlying type: Number: Do not cast the result of pow() to an i64, and perform the follow-up multiplication with doubles. BigInt: Do not use pow(). Instead, compute the exponent as a BigInt from the start, then perform the follow-up multiplication with that BigInt.
2022-07-16 11:39:11 -04:00
static ALWAYS_INLINE Value divide_by_power(GlobalObject& global_object, Value number, i8 exponent)
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
{
LibJS: Prevent i64 overflow when computing large NumberFormat exponents The largest exponents we compute are on the order of 10^21 (governed by the maximumSignificantDigits option, which has a max value of 21). That is too large to fit into the i64 we were using when multiplying this exponent by the value to be formatted. Instead, split up the logic to multiply that value by this exponent based on the value's underlying type: Number: Do not cast the result of pow() to an i64, and perform the follow-up multiplication with doubles. BigInt: Do not use pow(). Instead, compute the exponent as a BigInt from the start, then perform the follow-up multiplication with that BigInt.
2022-07-16 11:39:11 -04:00
if (number.is_number()) {
if (exponent < 0)
return Value(number.as_double() * pow(10, -exponent));
return Value(number.as_double() / pow(10, exponent));
}
if (exponent < 0) {
auto exponent_bigint = bigint_power(10, -exponent);
return js_bigint(global_object.vm(), number.as_bigint().big_integer().multiplied_by(exponent_bigint));
}
auto exponent_bigint = bigint_power(10, exponent);
return js_bigint(global_object.vm(), number.as_bigint().big_integer().divided_by(exponent_bigint).quotient);
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
}
static ALWAYS_INLINE Value rounded(Value number)
{
if (number.is_number())
return Value(round(number.as_double()));
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
return number;
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
}
static ALWAYS_INLINE bool is_zero(Value number)
{
if (number.is_number())
return number.as_double() == 0.0;
LibJS: Replace comparisons of "0"_bigint with SignedBigInteger::is_zero This just avoids creating UnsignedBigInteger's underlying vector.
2022-07-16 12:43:23 -04:00
return number.as_bigint().big_integer().is_zero();
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
}
static ALWAYS_INLINE bool is_greater_than(Value number, i64 rhs)
{
if (number.is_number())
return number.as_double() > rhs;
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
return number.as_bigint().big_integer() > Crypto::SignedBigInteger::create_from(rhs);
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
}
static ALWAYS_INLINE bool is_less_than(Value number, i64 rhs)
{
if (number.is_number())
return number.as_double() < rhs;
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
return number.as_bigint().big_integer() < Crypto::SignedBigInteger::create_from(rhs);
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
}
static ALWAYS_INLINE String number_to_string(Value number)
{
if (number.is_number())
return number.to_string_without_side_effects();
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
return number.as_bigint().big_integer().to_base(10);
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.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: Mark the NumberFormat parameter of FormatNumericToString as const Not critical, but in subsequent commits this will be invoked from a constant context.
2022-07-07 09:55:52 -04:00
FormatResult format_numeric_to_string(GlobalObject& global_object, NumberFormatBase const& intl_object, Value 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: Normalize mathematical references to negative zero This is an editorial change in the Intl spec. See: https://github.com/tc39/ecma402/commit/d4be24e
2022-03-28 13:10:33 -04:00
// 1. If ℝ(x) < 0 or x is -0𝔽, let isNegative be true; else let isNegative be false.
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
bool is_negative = is_less_than(number, 0) || number.is_negative_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
// 2. If isNegative, then
if (is_negative) {
// a. Let x be -x.
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
number = multiply(global_object, number, -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
}
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: 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. 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: 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 result be ToRawPrecision(x, intlObject.[[MinimumSignificantDigits]], intlObject.[[MaximumSignificantDigits]]).
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
result = to_raw_precision(global_object, number, intl_object.min_significant_digits(), intl_object.max_significant_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
break;
// 4. 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: 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 result be ToRawFixed(x, intlObject.[[MinimumFractionDigits]], intlObject.[[MaximumFractionDigits]]).
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
result = to_raw_fixed(global_object, number, intl_object.min_fraction_digits(), intl_object.max_fraction_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
break;
// 5. 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).
auto significant_result = to_raw_precision(global_object, number, intl_object.min_significant_digits(), intl_object.max_significant_digits());
// b. Let fResult be ToRawFixed(x, intlObject.[[MinimumFractionDigits]], intlObject.[[MaximumFractionDigits]], intlObject.[[RoundingIncrement]], unsignedRoundingMode).
auto fraction_result = to_raw_fixed(global_object, number, intl_object.min_fraction_digits(), intl_object.max_fraction_digits());
// 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();
}
// 6. Let x be result.[[RoundedNumber]].
number = result.rounded_number;
// 7. Let string be result.[[FormattedString]].
auto string = move(result.formatted_string);
// 8. Let int be result.[[IntegerDigitsCount]].
int digits = result.digits;
// 9. 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
// 10. If int < minInteger, then
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);
}
// 11. If isNegative, then
if (is_negative) {
// a. Let x be -x.
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
number = multiply(global_object, number, -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
}
// 12. Return the Record { [[RoundedNumber]]: x, [[FormattedString]]: string }.
return { move(string), number };
}
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: 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
Vector<PatternPartition> partition_number_pattern(GlobalObject& global_object, NumberFormat& number_format, Value 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;
// 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. 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: 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
// 3. Else if x is +∞, 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: 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
// 4. Else if x is -∞, 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 {
// a. If numberFormat.[[Style]] is "percent", let x be 100 × x.
if (number_format.style() == NumberFormat::Style::Percent)
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
number = multiply(global_object, number, 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
// b. Let exponent be ComputeExponent(numberFormat, x).
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
exponent = compute_exponent(global_object, 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
// c. Let x be x × 10^(-exponent).
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
number = multiply_by_power(global_object, number, -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
// d. Let formatNumberResult be FormatNumericToString(numberFormat, x).
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
auto format_number_result = format_numeric_to_string(global_object, 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
// e. Let n be formatNumberResult.[[FormattedString]].
formatted_string = move(format_number_result.formatted_string);
// f. Let x be formatNumberResult.[[RoundedNumber]].
number = format_number_result.rounded_number;
}
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: 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
auto pattern = get_number_format_pattern(global_object, 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: 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
auto notation_sub_parts = partition_notation_sub_pattern(global_object, 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: 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
Vector<PatternPartition> partition_notation_sub_pattern(GlobalObject& global_object, NumberFormat& number_format, Value 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: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
else if (number.is_number() && !number.is_finite_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
// 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: 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 exponentResult be ToRawFixed(exponent, 1, 0, 0).
LibJS: Implement engineering and scientific number formatting
2021-11-14 10:03:31 -05:00
// Note: See the implementation of ToRawFixed for why we do not pass the 1.
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
auto exponent_result = to_raw_fixed(global_object, Value(exponent), 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 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: 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
String format_numeric(GlobalObject& global_object, NumberFormat& number_format, Value 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: 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
auto parts = partition_number_pattern(global_object, 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
// 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: 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
Array* format_numeric_to_parts(GlobalObject& global_object, NumberFormat& number_format, Value number)
LibJS: Implement Intl.NumberFormat.prototype.formatToParts
2021-11-13 11:33:55 -05:00
{
auto& vm = global_object.vm();
// 1. Let parts be ? PartitionNumberPattern(numberFormat, x).
// Note: Our implementation of PartitionNumberPattern does not throw.
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
auto parts = partition_number_pattern(global_object, number_format, 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: Implement Intl.NumberFormat.prototype.formatToParts
2021-11-13 11:33:55 -05:00
auto* result = MUST(Array::create(global_object, 0));
// 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: Implement Intl.NumberFormat.prototype.formatToParts
2021-11-13 11:33:55 -05:00
auto* object = Object::create(global_object, global_object.object_prototype());
// 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: 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: 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
RawFormatResult to_raw_precision(GlobalObject& global_object, Value number, int min_precision, int max_precision)
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: 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
// 1. Set x to ℝ(x).
// 2. 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: 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
// 3. If x = 0, 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 (is_zero(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
// 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: 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
result.rounded_number = Value(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: 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
// 4. 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: 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
// a. Let e and n be integers such that 10^(p–1) ≤ n < 10^p and for which n × 10^(e–p+1) – x is as close to zero as possible.
// If there are two such sets of e and n, pick the e and n for which n × 10^(e–p+1) is larger.
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
exponent = log10floor(number);
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
Value n;
if (number.is_number()) {
n = rounded(divide_by_power(global_object, number, exponent - precision + 1));
} 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.
n = divide_by_power(global_object, number, exponent - precision);
// FIXME: Can we do this without string conversion?
auto digits = n.as_bigint().big_integer().to_base(10);
auto digit = digits.substring_view(digits.length() - 1);
n = divide(global_object, n, 10);
if (digit.to_uint().value() >= 5)
n = js_bigint(global_object.vm(), n.as_bigint().big_integer().plus(Crypto::SignedBigInteger::create_from(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: 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
// b. Let m be the String consisting of the digits of the decimal representation of n (in order, with no leading zeroes).
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
result.formatted_string = number_to_string(n);
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: 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
// c. Let xFinal be n × 10^(e–p+1).
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
result.rounded_number = multiply_by_power(global_object, n, 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
}
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
// 5. 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: 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
// 6. 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: 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
// 7. 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: 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
// 8. 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 [[RoundingPriority]] changes
2022-07-16 12:11:20 -04:00
// 9. Return the Record { [[FormattedString]]: m, [[RoundedNumber]]: xFinal, [[IntegerDigitsCount]]: int, [[RoundingMagnitude]]: e–p+1 }.
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: 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: 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
// NOTE: The spec has a mistake here. The minInteger parameter is unused and is not provided by FormatNumericToString.
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
RawFormatResult to_raw_fixed(GlobalObject& global_object, Value number, int min_fraction, int max_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
{
RawFormatResult result {};
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
// 1. Set x to ℝ(x).
// 2. 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: 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
// 3. Let n be an integer for which the exact mathematical value of n / 10^f – x is as close to zero as possible. If there are two such n, pick the larger n.
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
auto n = rounded(multiply_by_power(global_object, number, 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
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
// 4. Let xFinal be n / 10^f.
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
result.rounded_number = divide_by_power(global_object, n, 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
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
// 5. 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: 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
result.formatted_string = is_zero(n) ? String("0"sv) : number_to_string(n);
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: 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
// 6. 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: 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
// 7. 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: 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
// 8. 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: 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 9-10 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 [[RoundingPriority]] changes
2022-07-16 12:11:20 -04:00
// 11. Return the Record { [[FormattedString]]: m, [[RoundedNumber]]: xFinal, [[IntegerDigitsCount]]: int, [[RoundingMagnitude]]: –f }.
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: 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
Optional<Variant<StringView, String>> get_number_format_pattern(GlobalObject& global_object, NumberFormat& number_format, Value 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: 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
auto plurality = resolve_plural(global_object, number_format, Unicode::PluralForm::Cardinal, number);
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: 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
auto plurality = resolve_plural(global_object, number_format, Unicode::PluralForm::Cardinal, number);
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;
LibJS: Support BigInt number formatting with Intl.NumberFormat
2022-01-30 13:00:09 -05:00
bool is_positive_zero = number.is_positive_zero() || (number.is_bigint() && is_zero(number));
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
bool is_negative_zero = number.is_negative_zero();
bool is_nan = 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
// 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: 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 (is_positive_zero || is_greater_than(number, 0) || 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: 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 (is_positive_zero || is_greater_than(number, 0) || 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: 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
// a. If x is NaN, or if x is finite and ℝ(x) is 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 (is_positive_zero || is_negative_zero || is_nan) {
// i. Let pattern be patterns.[[zeroPattern]].
pattern = patterns->zero_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
// b. Else if ℝ(x) > 0, 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 (is_greater_than(number, 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
// 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
if (is_positive_zero || is_negative_zero || is_greater_than(number, 0) || is_nan) {
// 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: 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
int compute_exponent(GlobalObject& global_object, NumberFormat& number_format, Value 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: 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 (is_zero(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
// a. Return 0.
return 0;
}
// 2. If x < 0, 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 (is_less_than(number, 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
// a. Let x = -x.
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
number = multiply(global_object, number, -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
}
// 3. Let magnitude be the base 10 logarithm of x rounded down to the nearest integer.
int magnitude = log10floor(number);
// 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: 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
number = multiply_by_power(global_object, number, -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: 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
auto format_number_result = format_numeric_to_string(global_object, 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
// 7. If formatNumberResult.[[RoundedNumber]] = 0, 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 (is_zero(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
// a. Return exponent.
return exponent;
}
// 8. Let newMagnitude be the base 10 logarithm of formatNumberResult.[[RoundedNumber]] rounded down to the nearest integer.
int new_magnitude = log10floor(format_number_result.rounded_number);
// 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: 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