[Webkit-unassigned] [Bug 239724] New: Several internationalization tests broken with ICU 69.1
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Apr 25 08:32:31 PDT 2022
https://bugs.webkit.org/show_bug.cgi?id=239724
Bug ID: 239724
Summary: Several internationalization tests broken with ICU
69.1
Product: WebKit
Version: WebKit Nightly Build
Hardware: PC
OS: Linux
Status: NEW
Severity: Normal
Priority: P2
Component: JavaScriptCore
Assignee: webkit-unassigned at lists.webkit.org
Reporter: mcatanzaro at gnome.org
Created attachment 458272
--> https://bugs.webkit.org/attachment.cgi?id=458272&action=review
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 at array-toLocaleString.js:3:24
stress/array-toLocaleString.js.default: global code at 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 at 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 at intl-datetimeformat-formatrange-relevant-extensions-ja.js:9:24
stress/intl-datetimeformat-formatrange-relevant-extensions-ja.js.default: global code at 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 at intl-datetimeformat.js:3:24
stress/intl-datetimeformat.js.default: global code at 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 at intl-locale-info.js:3:24
stress/intl-locale-info.js.default: global code at 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 at intl-locale.js:3:24
stress/intl-locale.js.default: global code at 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');
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220425/00e743d1/attachment.htm>
More information about the webkit-unassigned
mailing list