This makes construction of Utf16String fallible in OOM conditions. The
immediate impact is that PrimitiveString must then be fallible as well,
as it may either transcode UTF-8 to UTF-16, or create a UTF-16 string
from ropes.
There are a couple of places where it is very non-trivial to propagate
the error further. A FIXME has been added to those locations.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
Since LibUnicode depends on this data it used to include
Intl/AbstractOperations which in turn includes a number of other LibJS
headers. By moving this to its own header with minimal includes we can
save on rebuilding LibUnicode for unrelated LibJS header changes.
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.
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.
This is an editorial change in the Intl spec. See:
https://github.com/tc39/ecma402/commit/087995chttps://github.com/tc39/ecma402/commit/233d29c
This also adds a missing spec link for the sanctioned units and fixes a
broken spec link for IsSanctionedSingleUnitIdentifier. In LibUnicode,
the NumberFormat generator is updated to use the constexpr helper to
retrieve sanctioned units.
Allocating a Vector for each of these invocations is a bit silly when
the values are basically all compile-time arrays. This AO is used even
more heavily by Intl.DateTimeFormat, so change it to accept a Span to
reduce its cost.
This also adds an overload to accept a fixed-size C-array so callers do
not have to be prefixed with AK::Array, i.e. this:
get_option(..., AK::Array { "a"sv, "b"sv }, ...);
Reduces to:
get_option(..., { "a"sv, "b"sv }, ...);
(Which is how all call sites were already written to construct a Vector
in place).
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.
Intl.DisplayNames was the first Intl object implemented, and at that
point all AOs were just put into the main Intl AO header. But AOs that
belong to specific objects belong in that object's header. So this moves
CanonicalCodeForDisplayNames to the Intl.DisplayNames header.
Currently, all callers of ResolveLocale invoke the operation with an
empty [[RelevantExtensionKeys]] slot, so the block of the method that
deals with those keys was unimplemented. This implements that block now
to prepare for Intl.NumberFormat which has a [[RelevantExtensionKeys]].
Note that the find_key_in_value() method is a simple VERIFY_NOT_REACHED
in just this commit until the Intl.NumberFormat's keys are handled in
its implementation.
Note that only option type=region is really implemented. Other types
will resort to the fallback option. This prototype method will be able
to implement other type options once LibUnicode supports more.
There is notably FIXME notations in this commit regarding Unicode locale
extensions. We are not parsing extensions (or private use extensions) at
all yet.
