Update JSTests to assume ICU 60+
Created attachment 395639 [details] Patch
Argh, the following test case depends on ICU version (incidentally one of the same cases affected by bug 154530 but in a new way): Intl.NumberFormat('es').format(1234.567) • using ICU 63 (WinCairo): 1.234,567 • using ICU 64 (Catalina): 1234,567 A simple fix would be to add a digit, in which case both use the thousands separator.
Created attachment 395649 [details] Patch
To elaborate a bit more about the 'es' locale change... Evidently this was a bug fix, since CLDR data specifies "minimumGroupingDigits" as 2 for Spanish: https://www.unicode.org/cldr/charts/35/by_type/numbers.symbols.html#70ef5e0c9d323e01 It is a surprising change though, so apparently folks have filed bugs about it elsewhere: https://unicode-org.atlassian.net/browse/CLDR-13676 https://bugs.chromium.org/p/chromium/issues/detail?id=1019268 Intl.NumberFormat V3 plans to make useGrouping an enum so that this can be better configured: https://github.com/tc39/proposal-intl-numberformat-v3#part-3-grouping-enum-ecma-402-367
Comment on attachment 395649 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=395649&action=review > JSTests/stress/intl-pluralrules.js:290 > -shouldBe(new Intl.PluralRules('ar').resolvedOptions().pluralCategories.join(), 'zero,one,two,few,many,other'); > +shouldBe(new Intl.PluralRules('ar').resolvedOptions().pluralCategories.join(), 'few,many,one,two,zero,other'); Also, regarding this fix to a previously-disabled test: ECMA-402 doesn't specify an order for these, so engines are all just keeping them in the order received from ICU.
Comment on attachment 395649 [details] Patch r=me
Committed r259658: <https://trac.webkit.org/changeset/259658> All reviewed patches have been landed. Closing bug and clearing flags on attachment 395649 [details].
<rdar://problem/61405323>