Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-30 21:01:00 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Runtime/Intl/NumberFormat.h

192 lines
11 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
/*
LibJS: Update spec numbers for the Intl.DurationFormat proposal This proposal has reached stage 4 and was merged into the ECMA-402 spec. See: https://github.com/tc39/ecma402/commit/3ff3cc7
2025-02-28 08:54:42 -05:00
* Copyright (c) 2021-2025, Tim Flynn <trflynn89@ladybird.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
*/
#pragma once
#include <AK/Optional.h>
LibJS: Port Intl locale resolution to String
2023-01-19 13:13:57 -05:00
#include <AK/String.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/AbstractOperations.h>
LibJS: Define constructor slots for describing how to read options This is an editorial change in the ECMA-402 spec. See: https://github.com/tc39/ecma402/commit/a2beb66 We implement this change by introducing a virtual interface that all Intl "service" objects must implement. A future patch will make use of the virtualized RelevantExtensionKeys and ResolutionOptionDescriptors accessors, and we will need to be able to use those slots from a generic instance type.
2025-04-07 15:56:31 -04:00
#include <LibJS/Runtime/Intl/IntlObject.h>
LibJS: Hook the Intl mathematical value into Intl.NumberFormat
2022-07-19 12:11:34 -04:00
#include <LibJS/Runtime/Intl/MathematicalValue.h>
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
#include <LibUnicode/Locale.h>
#include <LibUnicode/NumberFormat.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: Define constructor slots for describing how to read options This is an editorial change in the ECMA-402 spec. See: https://github.com/tc39/ecma402/commit/a2beb66 We implement this change by introducing a virtual interface that all Intl "service" objects must implement. A future patch will make use of the virtualized RelevantExtensionKeys and ResolutionOptionDescriptors accessors, and we will need to be able to use those slots from a generic instance type.
2025-04-07 15:56:31 -04:00
class NumberFormatBase : public IntlObject {
JS_OBJECT(NumberFormatBase, IntlObject);
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC_DECLARE_ALLOCATOR(NumberFormatBase);
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
public:
LibJS: Compute NumberFormat's rounding priority during construction This is an editorial change in the ECMA-402 spec. See: https://github.com/tc39/ecma402/commit/c28118e
2023-08-11 07:50:34 -04:00
enum class ComputedRoundingPriority {
Auto,
MorePrecision,
LessPrecision,
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
Invalid,
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
};
virtual ~NumberFormatBase() override = default;
LibJS: Port Intl locale resolution to String
2023-01-19 13:13:57 -05:00
String const& locale() const { return m_locale; }
void set_locale(String locale) { m_locale = move(locale); }
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_digits() const { return m_min_integer_digits; }
void set_min_integer_digits(int min_integer_digits) { m_min_integer_digits = min_integer_digits; }
bool has_min_fraction_digits() const { return m_min_fraction_digits.has_value(); }
int min_fraction_digits() const { return *m_min_fraction_digits; }
void set_min_fraction_digits(int min_fraction_digits) { m_min_fraction_digits = min_fraction_digits; }
bool has_max_fraction_digits() const { return m_max_fraction_digits.has_value(); }
int max_fraction_digits() const { return *m_max_fraction_digits; }
void set_max_fraction_digits(int max_fraction_digits) { m_max_fraction_digits = max_fraction_digits; }
bool has_min_significant_digits() const { return m_min_significant_digits.has_value(); }
int min_significant_digits() const { return *m_min_significant_digits; }
void set_min_significant_digits(int min_significant_digits) { m_min_significant_digits = min_significant_digits; }
bool has_max_significant_digits() const { return m_max_significant_digits.has_value(); }
int max_significant_digits() const { return *m_max_significant_digits; }
void set_max_significant_digits(int max_significant_digits) { m_max_significant_digits = max_significant_digits; }
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::RoundingType rounding_type() const { return m_rounding_type; }
StringView rounding_type_string() const { return Unicode::rounding_type_to_string(m_rounding_type); }
void set_rounding_type(Unicode::RoundingType rounding_type) { m_rounding_type = rounding_type; }
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
LibJS: Compute NumberFormat's rounding priority during construction This is an editorial change in the ECMA-402 spec. See: https://github.com/tc39/ecma402/commit/c28118e
2023-08-11 07:50:34 -04:00
ComputedRoundingPriority computed_rounding_priority() const { return m_computed_rounding_priority; }
StringView computed_rounding_priority_string() const;
void set_computed_rounding_priority(ComputedRoundingPriority computed_rounding_priority) { m_computed_rounding_priority = computed_rounding_priority; }
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::RoundingMode rounding_mode() const { return m_rounding_mode; }
StringView rounding_mode_string() const { return Unicode::rounding_mode_to_string(m_rounding_mode); }
void set_rounding_mode(StringView rounding_mode) { m_rounding_mode = Unicode::rounding_mode_from_string(rounding_mode); }
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
int rounding_increment() const { return m_rounding_increment; }
void set_rounding_increment(int rounding_increment) { m_rounding_increment = rounding_increment; }
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::TrailingZeroDisplay trailing_zero_display() const { return m_trailing_zero_display; }
StringView trailing_zero_display_string() const { return Unicode::trailing_zero_display_to_string(m_trailing_zero_display); }
void set_trailing_zero_display(StringView trailing_zero_display) { m_trailing_zero_display = Unicode::trailing_zero_display_from_string(trailing_zero_display); }
LibJS+LibLocale: Begin replacing number formatting with ICU This uses ICU for the Intl.NumberFormat `format` and `formatToParts` prototypes. It does not yet port the range formatter prototypes. Most of the new code in LibLocale/NumberFormat is simply mapping from ECMA-402 types to ICU types. Beyond that, the only algorithmic change is that we have to mutate the output from ICU for `formatToParts` to match what is expected by ECMA-402. This is explained in NumberFormat.cpp in `flatten_partitions`. This lets us remove most data from our number format generator. All that remains are numbering system digits and symbols, which are relied upon still for other interfaces (e.g. Intl.DateTimeFormat). So they will be removed in a future patch. Note: All of the changes to the test files in this patch are now aligned with both Chrome and Safari.
2024-06-09 14:36:48 -04:00
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::RoundingOptions rounding_options() const;
LibJS+LibLocale: Begin replacing number formatting with ICU This uses ICU for the Intl.NumberFormat `format` and `formatToParts` prototypes. It does not yet port the range formatter prototypes. Most of the new code in LibLocale/NumberFormat is simply mapping from ECMA-402 types to ICU types. Beyond that, the only algorithmic change is that we have to mutate the output from ICU for `formatToParts` to match what is expected by ECMA-402. This is explained in NumberFormat.cpp in `flatten_partitions`. This lets us remove most data from our number format generator. All that remains are numbering system digits and symbols, which are relied upon still for other interfaces (e.g. Intl.DateTimeFormat). So they will be removed in a future patch. Note: All of the changes to the test files in this patch are now aligned with both Chrome and Safari.
2024-06-09 14:36:48 -04:00
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::NumberFormat const& formatter() const { return *m_formatter; }
void set_formatter(NonnullOwnPtr<Unicode::NumberFormat> formatter) { m_formatter = move(formatter); }
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
LibJS: Hide all the constructors! Now that the GC allocator is able to invoke Cell subclass constructors directly via friendship, we no longer need to keep them public. :^)
2022-08-28 23:51:28 +02:00
protected:
explicit NumberFormatBase(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
private:
LibJS: Compute NumberFormat's rounding priority during construction This is an editorial change in the ECMA-402 spec. See: https://github.com/tc39/ecma402/commit/c28118e
2023-08-11 07:50:34 -04:00
String m_locale; // [[Locale]]
int m_min_integer_digits { 0 }; // [[MinimumIntegerDigits]]
Optional<int> m_min_fraction_digits {}; // [[MinimumFractionDigits]]
Optional<int> m_max_fraction_digits {}; // [[MaximumFractionDigits]]
Optional<int> m_min_significant_digits {}; // [[MinimumSignificantDigits]]
Optional<int> m_max_significant_digits {}; // [[MaximumSignificantDigits]]
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::RoundingType m_rounding_type; // [[RoundingType]]
LibJS: Compute NumberFormat's rounding priority during construction This is an editorial change in the ECMA-402 spec. See: https://github.com/tc39/ecma402/commit/c28118e
2023-08-11 07:50:34 -04:00
ComputedRoundingPriority m_computed_rounding_priority { ComputedRoundingPriority::Invalid }; // [[ComputedRoundingPriority]]
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::RoundingMode m_rounding_mode; // [[RoundingMode]]
LibJS: Compute NumberFormat's rounding priority during construction This is an editorial change in the ECMA-402 spec. See: https://github.com/tc39/ecma402/commit/c28118e
2023-08-11 07:50:34 -04:00
int m_rounding_increment { 1 }; // [[RoundingIncrement]]
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::TrailingZeroDisplay m_trailing_zero_display; // [[TrailingZeroDisplay]]
LibJS+LibLocale: Begin replacing number formatting with ICU This uses ICU for the Intl.NumberFormat `format` and `formatToParts` prototypes. It does not yet port the range formatter prototypes. Most of the new code in LibLocale/NumberFormat is simply mapping from ECMA-402 types to ICU types. Beyond that, the only algorithmic change is that we have to mutate the output from ICU for `formatToParts` to match what is expected by ECMA-402. This is explained in NumberFormat.cpp in `flatten_partitions`. This lets us remove most data from our number format generator. All that remains are numbering system digits and symbols, which are relied upon still for other interfaces (e.g. Intl.DateTimeFormat). So they will be removed in a future patch. Note: All of the changes to the test files in this patch are now aligned with both Chrome and Safari.
2024-06-09 14:36:48 -04:00
// Non-standard. Stores the ICU number formatter for the Intl object's formatting options.
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
OwnPtr<Unicode::NumberFormat> m_formatter;
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
};
class NumberFormat final : public NumberFormatBase {
JS_OBJECT(NumberFormat, NumberFormatBase);
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC_DECLARE_ALLOCATOR(NumberFormat);
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
public:
virtual ~NumberFormat() override = default;
LibJS: Define constructor slots for describing how to read options This is an editorial change in the ECMA-402 spec. See: https://github.com/tc39/ecma402/commit/a2beb66 We implement this change by introducing a virtual interface that all Intl "service" objects must implement. A future patch will make use of the virtualized RelevantExtensionKeys and ResolutionOptionDescriptors accessors, and we will need to be able to use those slots from a generic instance type.
2025-04-07 15:56:31 -04:00
virtual ReadonlySpan<StringView> relevant_extension_keys() const override;
virtual ReadonlySpan<ResolutionOptionDescriptor> resolution_option_descriptors(VM&) const override;
LibJS: Port Intl locale resolution to String
2023-01-19 13:13:57 -05:00
String const& numbering_system() const { return m_numbering_system; }
void set_numbering_system(String numbering_system) { m_numbering_system = move(numbering_system); }
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
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::NumberFormatStyle style() const { return m_style; }
StringView style_string() const { return Unicode::number_format_style_to_string(m_style); }
void set_style(StringView style) { m_style = Unicode::number_format_style_from_string(style); }
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
bool has_currency() const { return m_currency.has_value(); }
LibJS: Port Intl locale resolution to String
2023-01-19 13:13:57 -05:00
String const& currency() const { return m_currency.value(); }
void set_currency(String currency) { m_currency = move(currency); }
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
bool has_currency_display() const { return m_currency_display.has_value(); }
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::CurrencyDisplay currency_display() const { return *m_currency_display; }
StringView currency_display_string() const { return Unicode::currency_display_to_string(*m_currency_display); }
void set_currency_display(StringView currency_display) { m_currency_display = Unicode::currency_display_from_string(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
bool has_currency_sign() const { return m_currency_sign.has_value(); }
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::CurrencySign currency_sign() const { return *m_currency_sign; }
StringView currency_sign_string() const { return Unicode::currency_sign_to_string(*m_currency_sign); }
void set_currency_sign(StringView currency_sign) { m_currency_sign = Unicode::currency_sign_from_string(currency_sign); }
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
bool has_unit() const { return m_unit.has_value(); }
LibJS: Port Intl locale resolution to String
2023-01-19 13:13:57 -05:00
String const& unit() const { return m_unit.value(); }
void set_unit(String unit) { m_unit = move(unit); }
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
bool has_unit_display() const { return m_unit_display.has_value(); }
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::Style unit_display() const { return *m_unit_display; }
StringView unit_display_string() const { return Unicode::style_to_string(*m_unit_display); }
void set_unit_display(StringView unit_display) { m_unit_display = Unicode::style_from_string(unit_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
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::Grouping use_grouping() const { return m_use_grouping; }
LibJS: Stop propagating small OOM errors from Intl.NumberFormat Note this also does the same for Intl.PluralRules. The only OOM errors propagated from Intl.PluralRules were from Intl.NumberFormat.
2023-08-30 12:30:39 -04:00
Value use_grouping_to_value(VM&) const;
LibJS+js: Parse new constructor options from Intl.NumberFormat V3 This contains minimal changes to parse newly added and modified options from the Intl.NumberFormat V3 proposal, while maintaining main spec behavior in Intl.NumberFormat.prototype.format. The parsed options are reflected only in Intl.NumberFormat.prototype.resolvedOptions and the js REPL.
2022-07-12 13:18:23 -04:00
void set_use_grouping(StringOrBoolean const& use_grouping);
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
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::Notation notation() const { return m_notation; }
StringView notation_string() const { return Unicode::notation_to_string(m_notation); }
void set_notation(StringView notation) { m_notation = Unicode::notation_from_string(notation); }
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
bool has_compact_display() const { return m_compact_display.has_value(); }
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::CompactDisplay compact_display() const { return *m_compact_display; }
StringView compact_display_string() const { return Unicode::compact_display_to_string(*m_compact_display); }
void set_compact_display(StringView compact_display) { m_compact_display = Unicode::compact_display_from_string(compact_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
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::SignDisplay sign_display() const { return m_sign_display; }
StringView sign_display_string() const { return Unicode::sign_display_to_string(m_sign_display); }
void set_sign_display(StringView sign_display) { m_sign_display = Unicode::sign_display_from_string(sign_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
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
NativeFunction* bound_format() const { return m_bound_format; }
void set_bound_format(NativeFunction* bound_format) { m_bound_format = bound_format; }
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Unicode::DisplayOptions display_options() const;
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
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
private:
LibJS: Hide all the constructors! Now that the GC allocator is able to invoke Cell subclass constructors directly via friendship, we no longer need to keep them public. :^)
2022-08-28 23:51:28 +02:00
explicit NumberFormat(Object& prototype);
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
virtual void visit_edges(Visitor&) override;
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
String m_locale; // [[Locale]]
String m_numbering_system; // [[NumberingSystem]]
Unicode::NumberFormatStyle m_style; // [[Style]]
Optional<String> m_currency; // [[Currency]]
Optional<Unicode::CurrencyDisplay> m_currency_display; // [[CurrencyDisplay]]
Optional<Unicode::CurrencySign> m_currency_sign; // [[CurrencySign]]
Optional<String> m_unit; // [[Unit]]
Optional<Unicode::Style> m_unit_display; // [[UnitDisplay]]
Unicode::Grouping m_use_grouping { Unicode::Grouping::False }; // [[UseGrouping]]
Unicode::Notation m_notation; // [[Notation]]
Optional<Unicode::CompactDisplay> m_compact_display; // [[CompactDisplay]]
Unicode::SignDisplay m_sign_display; // [[SignDisplay]]
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<NativeFunction> m_bound_format; // [[BoundFormat]]
LibJS: Return an enum from ApplyUnsignedRoundingMode After the Intl MV is implemented, returning a copy of the desired value here may involve copying non-trivial data. Instead, return an enum to indicate which decision was made.
2022-07-19 12:27:54 -04:00
};
LibJS: Move Intl.NumberFormat's AOs to its object file
2021-09-11 11:09:18 -04:00
int currency_digits(StringView currency);
LibJS+LibLocale: Begin replacing number formatting with ICU This uses ICU for the Intl.NumberFormat `format` and `formatToParts` prototypes. It does not yet port the range formatter prototypes. Most of the new code in LibLocale/NumberFormat is simply mapping from ECMA-402 types to ICU types. Beyond that, the only algorithmic change is that we have to mutate the output from ICU for `formatToParts` to match what is expected by ECMA-402. This is explained in NumberFormat.cpp in `flatten_partitions`. This lets us remove most data from our number format generator. All that remains are numbering system digits and symbols, which are relied upon still for other interfaces (e.g. Intl.DateTimeFormat). So they will be removed in a future patch. Note: All of the changes to the test files in this patch are now aligned with both Chrome and Safari.
2024-06-09 14:36:48 -04:00
String format_numeric_to_string(NumberFormatBase const& intl_object, MathematicalValue const& number);
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
Vector<Unicode::NumberFormat::Partition> partition_number_pattern(NumberFormat const&, MathematicalValue const& number);
LibJS+LibLocale: Begin replacing number formatting with ICU This uses ICU for the Intl.NumberFormat `format` and `formatToParts` prototypes. It does not yet port the range formatter prototypes. Most of the new code in LibLocale/NumberFormat is simply mapping from ECMA-402 types to ICU types. Beyond that, the only algorithmic change is that we have to mutate the output from ICU for `formatToParts` to match what is expected by ECMA-402. This is explained in NumberFormat.cpp in `flatten_partitions`. This lets us remove most data from our number format generator. All that remains are numbering system digits and symbols, which are relied upon still for other interfaces (e.g. Intl.DateTimeFormat). So they will be removed in a future patch. Note: All of the changes to the test files in this patch are now aligned with both Chrome and Safari.
2024-06-09 14:36:48 -04:00
String format_numeric(NumberFormat const&, MathematicalValue const& number);
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<Array> format_numeric_to_parts(VM&, NumberFormat const&, MathematicalValue const& number);
LibJS: Replace GlobalObject with VM in Intl AOs [Part 1/19] Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
2022-08-20 08:25:24 +01:00
ThrowCompletionOr<MathematicalValue> to_intl_mathematical_value(VM&, Value value);
LibUnicode+Everywhere: Merge LibLocale back into LibUnicode LibLocale was split off from LibUnicode a couple years ago to reduce the number of applications on SerenityOS that depend on CLDR data. Now that we use ICU, both LibUnicode and LibLocale are actually linking in this data. And since vcpkg gives us static libraries, both libraries are over 30MB in size. This patch reverts the separation and merges LibLocale into LibUnicode again. We now have just one library that includes the ICU data. Further, this will let LibUnicode share the locale cache that previously would only exist in LibLocale.
2024-06-23 09:14:27 -04:00
ThrowCompletionOr<Vector<Unicode::NumberFormat::Partition>> partition_number_range_pattern(VM&, NumberFormat const&, MathematicalValue const& start, MathematicalValue const& end);
LibJS+LibLocale: Replace number range formatting with ICU This uses ICU for the Intl.NumberFormat `formatRange` and `formatRangeToParts` prototypes. Note: All of the changes to the test files in this patch are now aligned with both Chrome and Safari.
2024-06-09 19:26:25 -04:00
ThrowCompletionOr<String> format_numeric_range(VM&, NumberFormat const&, MathematicalValue const& start, MathematicalValue const& end);
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
ThrowCompletionOr<GC::Ref<Array>> format_numeric_range_to_parts(VM&, NumberFormat const&, MathematicalValue const& start, MathematicalValue const& end);
LibJS: Move Intl.NumberFormat's AOs to its object file
2021-09-11 11:09:18 -04:00
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