This relies on floating point division, which is not possible with
LibCrypto bigints at the moment. So, instead of completely ignoring the
remainder we now first do a bigint division, then convert the remainder
to a double, and do another native floating point division to get the
final result.
It would crash because of VERIFY(largest_unit == "nanosecond"sv) in the
final else branch when passing "week", because it's not handled in any
of the previous branches.
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.
Currently, LibUnicode is only parsing and generating the "long" style of
currency display names. However, the CLDR contains "short" and "narrow"
forms as well that need to be handled. Parse these, and update LibJS to
actually respect the "style" option provided by the user for displaying
currencies with Intl.DisplayNames.
Note: There are some discrepencies between the engines on how style is
handled. In particular, running:
new Intl.DisplayNames('en', {type:'currency', style:'narrow'}).of('usd')
Gives:
SpiderMoney: "USD"
V8: "US Dollar"
LibJS: "$"
And running:
new Intl.DisplayNames('en', {type:'currency', style:'short'}).of('usd')
Gives:
SpiderMonkey: "$"
V8: "US Dollar"
LibJS: "$"
My best guess is V8 isn't handling style, and just returning the long
form (which is what LibJS did before this commit). And SpiderMoney can
handle some styles, but if they don't have a value for the requested
style, they fall back to the canonicalized code passed into of().
I changed this in 6ef1a27 to "match the spec", but the spec calls it
`match exactly` and `match minutes` - so what we had before was correct
and the change made no sense whatsoever.
And use it to _correctly_ implement state saving for generators.
Prior to this, we were capturing the caller frame, which is completely
irrelevant to the generator frame.
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").
It was previously holding a StringView, which was either a view into a
LibUnicode-generated string or a string passed from the user.
Intl.NumberFormat will need this record to hold internally-created
strings, so a StringView will not suffice (the way the steps are laid
out, that view will ultimately end up dangling).
This shouldn't be too wasteful since the StringView it was holding was
converted to a String eventually anyways.
Always throws at the moment, because parse_temporal_month_day_string()
is basically a stub, and parse_iso_date_time() isn't functional either.
The spec issue has been resolved though, so I figured we might as well
get one small step further :^)
This commit adds support for the most bare bones version of async
functions, support for async generator functions, async arrow functions
and await expressions are TODO.
With one caveat: in the PreparePartialTemporalFields AO I made a change
to fix a spec issue that would require the input object to always have a
month or monthCode property.
This is tracked in https://github.com/tc39/proposal-temporal/issues/1910
and may get accepted as-is, in which case we simply need to remove the
NOTE comment.
