Created attachment 458272 [details] Failures Red Hat has upgraded its internal JSC CI from Fedora 34 to Fedora 35, which included an upgrade from ICU 67.1 to 69.1. This broke the following JSC stress tests: stress/array-toLocaleString.js stress/date-toLocaleString.js stress/intl-datetimeformat-formatrange-relevant-extensions-ja.js stress/intl-datetimeformat-formatrangetoparts-relevant-extensions-ja.js stress/intl-datetimeformat.js stress/intl-locale-info.js stress/intl-locale.js I've have attached a text file showing these failures. Next, I'll try to concoct a patch to make the tests more accommodating. The first two failures look like this: Running stress/array-toLocaleString.js.default stress/array-toLocaleString.js.default: Exception: Error: expected Invalid Date,一九七〇/一/一 〇〇:〇〇:〇〇 but got Invalid Date,一九七〇/一/一 上午一二:〇〇:〇〇 stress/array-toLocaleString.js.default: shouldBe@array-toLocaleString.js:3:24 stress/array-toLocaleString.js.default: global code@array-toLocaleString.js:41:9 stress/array-toLocaleString.js.default: ERROR: Unexpected exit code: 3 FAIL: stress/array-toLocaleString.js.default Notice that the test *already* anticipated (since 245210@main) that an ICU upgrade would change behavior here: shouldBe([ new Date(NaN), new Date(0) ].toLocaleString('zh-Hans-CN-u-nu-hanidec', { timeZone: 'UTC' }), $vm.icuVersion() >= 69 ? 'Invalid Date,一九七〇/一/一 〇〇:〇〇:〇〇' : 'Invalid Date,一九七〇/一/一 上午一二:〇〇:〇〇'); However, the version check is wrong. The test expects ICU 69 and higher to produce 一九七〇/一/一 〇〇:〇〇:〇〇, but in fact ICU 69.1 actually produces 一九七〇/一/一 上午一二:〇〇:〇〇. It's not the first time we've seen difference in behavior between the same ICU major version on macOS and on Linux. I suspect the ICU major version is not what actually matters here: perhaps the behavior changed in a CLDR update, which occur in ICU minor versions? The next two failures look like this: Running stress/intl-datetimeformat-formatrange-relevant-extensions-ja.js.default stress/intl-datetimeformat-formatrange-relevant-extensions-ja.js.default: Exception: Error: bad value: 丙戌年11月22日 2:00 expected value: 丙戌-11-22 2:00 stress/intl-datetimeformat-formatrange-relevant-extensions-ja.js.default: shouldBe@intl-datetimeformat-formatrange-relevant-extensions-ja.js:9:24 stress/intl-datetimeformat-formatrange-relevant-extensions-ja.js.default: global code@intl-datetimeformat-formatrange-relevant-extensions-ja.js:74:13 stress/intl-datetimeformat-formatrange-relevant-extensions-ja.js.default: ERROR: Unexpected exit code: 3 FAIL: stress/intl-datetimeformat-formatrange-relevant-extensions-ja.js.default Again, the behavior difference is anticipated, but the version test is incorrect: shouldBe(fmt2.format(date1), $vm.icuVersion() >= 69 ? `丙戌-11-22 2:00` : `丙戌年11月22日 2:00`); The fifth failure looks like this: Running stress/intl-datetimeformat.js.default stress/intl-datetimeformat.js.default: Exception: Error: expected 〇〇:〇〇:〇〇.〇〇 but got 上午一二:〇〇:〇〇.〇〇 stress/intl-datetimeformat.js.default: shouldBe@intl-datetimeformat.js:3:24 stress/intl-datetimeformat.js.default: global code@intl-datetimeformat.js:766:13 stress/intl-datetimeformat.js.default: ERROR: Unexpected exit code: 3 Again, another unsuccessful attempt to handle this by checking ICU version: shouldBe(new Date(0).toLocaleTimeString('zh-Hans-CN', { timeZone: 'UTC', numberingSystem: 'hanidec', hour: "numeric", minute: "numeric", second: "numeric", fractionalSecondDigits: 2 }), $vm.icuVersion() >= 69 ? "〇〇:〇〇:〇〇.〇〇" : "上午一二:〇〇:〇〇.〇〇"); The sixth failure looks like this: stress/intl-locale-info.js.default: Exception: Error: expected ["h23"] but got ["h12"] stress/intl-locale-info.js.default: shouldBe@intl-locale-info.js:3:24 stress/intl-locale-info.js.default: global code@intl-locale-info.js:91:13 stress/intl-locale-info.js.default: ERROR: Unexpected exit code: 3 FAIL: stress/intl-locale-info.js.default The pattern continues: shouldBe(JSON.stringify(locale.hourCycles), $vm.icuVersion() >= 69 ? `["h23"]` : `["h12"]`); Finally, the last failure: Running stress/intl-locale.js.default stress/intl-locale.js.default: Exception: Error: expected xtg-Arab-u-nu-gujr but got cel-Arab-gaulish-u-nu-gujr stress/intl-locale.js.default: shouldBe@intl-locale.js:3:24 stress/intl-locale.js.default: global code@intl-locale.js:155:9 stress/intl-locale.js.default: ERROR: Unexpected exit code: 3 FAIL: stress/intl-locale.js.default This last failure is notable because it is the only case where the actual result does not match either expected result: shouldBe(new Intl.Locale('cel-gaulish', { script: 'Arab', numberingSystem: 'gujr' }).toString(), $vm.icuVersion() >= 69 ? 'xtg-Arab-u-nu-gujr' : 'xtg-Arab-u-nu-gujr-x-cel-gaulish');
Interestingly, ICU doesn't release .0 versions and there is no 69.2, so ICU 69.1 is the *only* released version of ICU 69. Fedora 35 uses a vanilla upstream tarball release without patches, so my guess is that the Apple version of ICU does not exactly match the released version. E.g. maybe your "ICU 69" is really a snapshot from after 69 but before 70.
https://github.com/WebKit/WebKit/pull/383
Committed r293445 (250000@main): <https://commits.webkit.org/250000@main> Reviewed commits have been landed. Closing PR #383 and removing active labels.
<rdar://problem/92352885>