This method represents the Intl.NumberFormat's [[RelevantExtensionKeys]]
internal slot, so it makes more sense for this to be directly in the
class itself.
To be consistent with the style in Temporal, let's move all AOs in Intl
to their object file, rather than splitting the AOs between prototype
and constructor files.
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.
Previously, LibUnicode would store the values of a keyword as a Vector.
For example, the locale "en-u-ca-abc-def" would have its keyword "ca"
stored as {"abc, "def"}. Then, canonicalization would occur on each of
the elements in that Vector.
This is incorrect because, for example, the keyword value "true" should
only be dropped if that is the entire value. That is, the canonical form
of "en-u-kb-true" is "en-u-kb", but "en-u-kb-abc-true" does not change
for canonicalization. However, we would canonicalize that locale as
"en-u-kb-abc".
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.
The keyword accessors all have the same function body in the spec,
except for the Intl.Locale method they invoke. This generates those
properties in the same manner as RegExp.prototype.
Intl.Locale.prototype.calendar
Intl.Locale.prototype.caseFirst
Intl.Locale.prototype.collation
Intl.Locale.prototype.hourCycle
Intl.Locale.prototype.numberingSystem
The exception is Intl.Locale.prototype.numeric, which will be defined
separately because it is a boolean value.
This isn't particularly testable yet without the Intl.Locale constructor
but having this defined will make testing the constructor possible. So
more specific tests for this prototype will come later.
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.
