[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