Derive the supported collations from the per-locale lists - #3006
Merged
lahma merged 1 commit intoAug 13, 2026
Conversation
Intl.supportedValuesOf("collation") was a third hardcoded collation list, in
DefaultCldrProvider.GetSupportedCollations, next to the per-language table and
the root pair the other two views read.
https://tc39.es/ecma402/#sec-availablecanonicalcollations asks for "the
collations for which the implementation provides the functionality of
Intl.Collator objects", sorted in lexicographic code unit order and unique -
which is the union of the one [[co]] list every locale has and nothing else, so
there was never a second fact for that list to hold. It is now read off
LocaleCollations, the same derived data getCollations and Intl.Collator resolve
against.
It agreed with them when this was written, and the previous change is what made
that true again - but agreeing today is exactly what the two views did before
sebastienros#2974. The failure modes are asymmetric and only one of them is caught:
a value listed that no locale resolves turns
intl402/Intl/supportedValuesOf/collations-accepted-by-Collator.js red, which is
how the deprecated CLDR types were noticed, while a collation some locale
reports and the list omits is invisible to test262 - AvailableCollations is
implementation-defined, so nothing checks it from that side. Adding a collation
to LocaleCollationSupport used to produce exactly that silent second case; it
now shows up in all three views by the same act.
"standard", "search" and "default" need no exclusion of their own here.
IsReportableCollation already keeps them out of every list being unioned, which
is what https://tc39.es/ecma402/#sec-intl-collator-internal-slots (10.2.3)
requires of the per-locale lists and what
intl402/Intl/supportedValuesOf/collations.js checks of this one - the same
guard now answering for both. Sorting is likewise not restated: the union is
built in code unit order, which is what 15.5.10 and this clause both ask for
and what IntlInstance.SupportedValuesOf sorts by anyway.
The values are unchanged: compat, dict, emoji, eor, phonebk, phonetic, pinyin,
searchjl, stroke, trad, unihan and zhuyin, the same twelve the hardcoded list
ended at. The tests pin both the derivation - the union over every language,
built from getCollations rather than from the expected answer - and that
literal list, so a change to the table has to be a deliberate edit in two
places rather than a silent divergence in one.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The follow-up #2989's commit message promised:
Intl.supportedValuesOf("collation")was backed byDefaultCldrProvider.GetSupportedCollations(), a third hand-kept list not derived fromLocaleCollationSupport— consistent today only because #2989 edited it in the same commit, and free to drift exactly the way the #2974 bug did. It is now the union of every per-language list plus the root pair, per AvailableCanonicalCollations: sorted in ascending code-unit order, unique, withstandard/searchexcluded at derivation (theIsReportableCollationfilter, so a future table edit cannot reintroduce them).A behavioural red is impossible — #2989 already made the hand-kept list agree — so the test's teeth were proven by injection: adding one fake collation to the table makes
SupportedValuesOfCollationIsTheUnionOfEveryLocalesCollationsfail against a hardcoded list and pass once derived. Injection reverted; the reported values are unchanged at the same twelve. test262'scollations-accepted-by-Collator.jsstays green.Rebased onto current main after #2989's merge; IntlTests 171/171 on both TFMs.
🤖 Generated with Claude Code