Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Various fixes for ECMA-402 2020 #418

Merged
merged 41 commits into from
Mar 30, 2020
Merged

Conversation

anba
Copy link
Contributor

@anba anba commented Mar 16, 2020

I've started with fixing #413, but things to fix just piled up. 🤷‍♂️

Other potential issues I've noticed while working on this PR:

  1. There doesn't seem to be a good CLDR replacement for RFC 4647, so we're still stuck with some references to "BCP 47" which don't quite mean "Unicode BCP 47 locale identifiers" (cf. "BCP 47 language priority list").
  2. The number formatter is a bit loose with performing mathematical operations on mixed Number/BigInt inputs. I think ECMA-262 is nowadays a bit more strict in this regard.

@leobalter
Copy link
Member

things to fix just piled up. 🤷‍♂

I never liked things to fix just piling up the way I like it here.

I like everything I see here and honestly this looks good enough for me to get a candidate version for 2020. I'd have a rollback version in case it becomes necessary.


@sffc let's get this for the TC39-TG2 meeting next week?

@sffc
Copy link
Contributor

sffc commented Mar 16, 2020

Thanks for all the detail work! I think we should definitely get this in before we cut 2020. (I haven't completely reviewed it yet)

spec/numberformat.html Outdated Show resolved Hide resolved
spec/negotiation.html Outdated Show resolved Hide resolved
anba added 25 commits March 30, 2020 09:26
This is now handled automatically as part of the canonicalisation in ResolveLocale.
…ze operation

Drive-by fix: Add a missing "then".
…e identifier

Also remove the reference to BCP 47 RFCs in the normative references section.
…tag canonicalisation

We're now refering to UTS 35 for all canonicalisation, so the additional
canonicalisation allowed through this Annex A clause is no longer relevant.
Section 9.1 requires for the Intl service constructor to have an [[AvailableLocales]]
internal slot, which isn't provided by Intl.Locale.
…nComponents

UnicodeExtensionValue was only called in one place and that call can be
replaced with the new UnicodeExtensionComponents operation.
…AndCanonicalize into section 9

Both operations are now also called in section 9 in addition to section 10, so
it seems useful to move them into section 9.
The assertion must always hold, so it seems confusing to perform it only
within a conditional step.
- Replace [[Fields]] with [[DataLocale]] to match the approach taken in Intl.NumberFormat.
- Fix operation name in PartitionRelativeTimePattern preamble.
- Update Intl.RelativeTimeFormat internal slots to use Records instead of objects.
- Replace reference to non-existent [[PluralCategories]] slot with prose.
- Mention [[NumberFormat]] and [[PluralRules]] in internal slots overview.
- Add short Annex A entry for Intl.RelativeTimeFormat.
And remove extra 'for all locale values' in DateTimeFormat.
…after accessing the property

And also align the missing "unit" check to match how "currency" is processed.

This change ensures the missing "currency" check matches how ECMA-402 2019
and predecessors handled this case. It also minimises the observable differences
on how number format options are processed between ECMA-402 2019 and 2020.
There's no clear objective advantage to check missing properties at a later
point, so keeping the original steps order is preferable.
anba added 16 commits March 30, 2020 09:26
…imeFormat

And also for the two "Unwrap[...]Format" operations, which weren't updated for
some reason.
The "or successor" text in this context was originally used in reference to
a specific RFC number, but in its current context when referencing to UTS 35,
it doesn't make sense anymore to say "or successor".
This matches the convention from ECMA-262.
Reword the first paragraph by comparing what it did say in ECMA-402 5th edition.
Use "Else if" to avoid falling into the "Else" at step 14.g for `p` == "literal".

Drive-by: Correct "Else If" to "Else if".
Tests for absent fields must be performed explicitly.
"zeroes" seems to be the OED spelling and is also used elsewhere in ECMA-402 and ECMA-262.
@anba anba force-pushed the ca-nu-unicode-opt-canon branch from cca232e to 83f310f Compare March 30, 2020 16:27
@leobalter leobalter merged commit 4ec8987 into tc39:master Mar 30, 2020
@anba anba mentioned this pull request Mar 31, 2020
ptomato added a commit to ptomato/test262 that referenced this pull request Jul 3, 2024
This ECMA-402 change is already from several years ago, but lacked test
coverage: tc39/ecma402#418
ptomato added a commit to ptomato/test262 that referenced this pull request Jul 4, 2024
This ECMA-402 change is already from several years ago, but lacked test
coverage: tc39/ecma402#418
Ms2ger pushed a commit to ptomato/test262 that referenced this pull request Jul 4, 2024
This ECMA-402 change is already from several years ago, but lacked test
coverage: tc39/ecma402#418
Ms2ger pushed a commit to tc39/test262 that referenced this pull request Jul 4, 2024
This ECMA-402 change is already from several years ago, but lacked test
coverage: tc39/ecma402#418
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants