ApplyUnicodeExtensionToTag and ResolveLocale set the result record's internal slots to non-canonical values

[trflynn89]

In ApplyUnicodeExtensionToTag and ResolveLocale, we loop over the provided relevant extension keys, and set the corresponding internal slot of the result record to the value present in either the locale string or options object:

6. For each element key of relevantExtensionKeys, do
    ...
    g. Set result.[[<key>]] to value.

This happens before the values are canonicalized via InsertUnicodeExtensionAndCanonicalize:

9. If newExtension is not the empty String, then
    a. Let locale be ! InsertUnicodeExtensionAndCanonicalize(locale, newExtension)    .
10. Set result.[[locale]] to locale.
11. Return result.

Thus, the locale string of the corresponding Intl object is canonicalized, but the extension key internal slots are non-canonical.

The formatjs polyfill shows this issue:

import '@formatjs/intl-locale/polyfill.js'

const loc = new Intl.Locale('en', {calendar: 'islamicc'});
console.log(loc.toString());
console.log(loc.calendar);

That prints:

en-u-ca-islamic-civil
islamicc

test262 expects loc.calendar to be canonicalized (and that is how v8 and spidermonkey already behave).

[FrankYFTang]

We discuss this in TG2 Dec 14 2023 and think it is truely an issue. Frank will take action to produce a Normative PR around step 5.f / 5.g of ApplyUnicodeExtensionToTag which similar to what ResolveLocale did in

step 9.i.iii.3 "3. Set optionsValue to the String value resulting from canonicalizing optionsUValue as a value of key ukey per Unicode Technical Standard #35 Part 1 Core, Annex C LocaleId Canonicalization Section 5 Canonicalizing Syntax, Processing LocaleIds."

@FrankYFTang
@gibson042 said he will review that PR

[FrankYFTang]

Proposed fix in #846

[sffc]

TG2 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2023-12-14.md#applyunicodeextensiontotag-and-resolvelocale-set-the-result-records-internal-slots-to-non-canonical-values-707