Bug 239724

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');