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.
We move the input string into this field to avoid a string copy, so we
must do this step last to avoid using any views into it (note that
match.view here is a view into this string).
Userland/Libraries/LibJS/Runtime/Temporal/PlainTime.cpp:283:24:
note: deduced conflicting types for parameter 'T' ('long long int'
and 'long int')
283 | nanosecond = modulo(nanosecond, 1000l);
| ~~~~~~^~~~~~~~~~~~~~~~~~~
Worked fine on x86_84 :yakshrug:
Two issues:
- The format string said "{:9}", which left-pads with spaces and not
zeros as required
- Even when correcting that, we were not accounting for step 11 b:
"Set fraction to the longest possible substring of fraction starting
at position 0 and not ending with the code unit 0x0030 (DIGIT ZERO)."
We can safely use trim() for that as the formatted string is known to
not contain only zeros (which would leave the left-most in place).
Also adds tests for "UTC" and various numeric offsets.
We're supposed to get the substring from `fraction`, which is guaranteed
to have the required length. `fraction_part` is the user-supplied value
and trying to get a substring view from 0-9 might crash.
