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).
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.
This was one of the first AOs used for Intl, and I misinterpreted the
spec. Rather than removing all extensions, we must only remove Unicode
locale extensions.
Also use LocaleID::to_string() here instead of the heavier canonical
string method, because the locale is already canonical.
In the IsStructurallyValidLanguageTag AO, we of course cannot assume the
variants are canonicalized to lower-case yet, because canonicalization
hasn't happened yet.
ErrorType::IntlInvalidCode has almost exactly the same message as
ErrorType::OptionIsNotValidValue. Remove it, as all uses of the former
are semantically interchangeable with the latter.
Originally, it was convenient to store the parsed Unicode locale data as
views into the original string being parsed. But to implement locale
aliases will require mutating the data that was parsed. To prepare for
that, store the parsed data as proper strings.
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.
