Update our in-tree ICU to 69
Categories
(Core :: JavaScript: Internationalization API, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox91 | --- | fixed |
People
(Reporter: anba, Assigned: anba)
References
Details
Attachments
(8 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
Also updates to CLDR 39 and brings various bug fixes and improvements.
Release notes: http://site.icu-project.org/download/69
Assignee | ||
Comment 1•4 years ago
|
||
Generate the WASI patch from bug 1706949 to apply cleanly on ICU 69.
Assignee | ||
Comment 2•4 years ago
|
||
Update to ICU 69.1 by running "update-icu.sh" with "maint/maint-69" as the target.
Depends on D116967
Assignee | ||
Comment 3•4 years ago
|
||
Re-run
./make_intl_data.py numbering
./make_intl_data.py units
./make_intl_data.py langtags
./make_intl_data.py tzdata
to update numbering systems, measurement units, language tags, and time zone data.
Also remove the "US/Pacific-New" link from otherICULegacyLinks()
because it
is no longer needed. Output from ./make_intl_data.py tzdata
with the link
still present:
Info: Link 'US/Pacific-New -> America/Los_Angeles' can be removed from otherICULegacyLinks()
Depends on D116968
Assignee | ||
Comment 4•4 years ago
|
||
Updating to CLDR 39 means a couple of format strings have changed, update the
expected results accordingly.
unicode-bcp47-locale-ids-language-mappings.js:
Replace "no -> nb" mapping with "tl -> fil" mapping, because CLDR 39 removed
the "no -> nb" mapping [1,2]. Use the "tl -> fil" mapping as the replacement,
because it is only present in CLDR, but not in the IANA language data registry.
[1] https://unicode-org.atlassian.net/browse/CLDR-2698
[2] https://unicode-org.atlassian.net/browse/CLDR-14493
Depends on D116969
Assignee | ||
Comment 5•4 years ago
|
||
Change the system requirement to ICU 69 in order to remove some conditional
code in the next patch.
Depends on D116971
Assignee | ||
Comment 6•4 years ago
|
||
udtitvfmt_formatToResult
and udtitvfmt_formatCalendarToResult
were both
promoted to stable in ICU 69, so we can remove the U_HIDE_DRAFT_API
for this
code.
Depends on D116972
Assignee | ||
Comment 7•4 years ago
|
||
Depends on D116973
Comment 9•3 years ago
|
||
Backed out for causing failures on test_ManifestProcessor_lang.html
Backout link: https://hg.mozilla.org/integration/autoland/rev/7d2575d16c1d2be25ecb3a8cfcacb7f75953f9a1
Failure log: https://treeherder.mozilla.org/logviewer?job_id=342716397&repo=autoland&lineNumber=6934
Assignee | ||
Comment 10•3 years ago
|
||
"no" is no longer canonicalised to "nb" in CLDR 39.
Assignee | ||
Updated•3 years ago
|
Comment 11•3 years ago
|
||
Comment 12•3 years ago
•
|
||
Backed out 8 changesets (Bug 1714933) for causing build bustages in 1659595.js CLOSED TREE
Log: https://treeherder.mozilla.org/logviewer?job_id=342744581&repo=autoland&lineNumber=60511
https://treeherder.mozilla.org/logviewer?job_id=342744560&repo=autoland&lineNumber=994
We've also started to see these failures:
https://treeherder.mozilla.org/logviewer?job_id=342745711&repo=autoland&lineNumber=1516
https://treeherder.mozilla.org/logviewer?job_id=342745710&repo=autoland&lineNumber=1516
https://treeherder.mozilla.org/logviewer?job_id=342745714&repo=autoland&lineNumber=1515
https://treeherder.mozilla.org/logviewer?job_id=342745715&repo=autoland&lineNumber=1515
https://treeherder.mozilla.org/logviewer?job_id=342745713&repo=autoland&lineNumber=1516
https://treeherder.mozilla.org/logviewer?job_id=342745716&repo=autoland&lineNumber=1515
https://treeherder.mozilla.org/logviewer?job_id=342745712&repo=autoland&lineNumber=1516
which appeared on tier1 afterwards as well
Backout: https://hg.mozilla.org/integration/autoland/rev/30ff85170f4f637ac4fd9e9fa14e039898753446
Assignee | ||
Comment 13•3 years ago
|
||
I don't understand why this failed. The error logs contain:
JS_Init failed: u_init() failed
which clearly indicates an error when initialising ICU. But when I push the changes to the try-server, I can't reproduce these failures: https://treeherder.mozilla.org/jobs?repo=try&revision=51fa58f8349acd6bea81d868db9ae215a41bb262. (And I can neither reproduce the failures locally.)
The errors for "Windows 2012 x64 debug" are also baffling to me:
[task 2021-06-14T20:54:58.624Z] 6:06.51 lld-link: error: relocation against symbol in discarded section: icudt69_dat
[task 2021-06-14T20:54:58.624Z] 6:06.51 >>> referenced by z:\task_1623694336\src\intl\icu\source\common\udata.cpp:698
[task 2021-06-14T20:54:58.624Z] 6:06.51 >>> ......\config\external\icu\common\udata.obj:(struct UDataMemory * __cdecl openCommonData(char const *, int, enum UErrorCode *))
[task 2021-06-14T20:54:58.624Z] 6:06.51 >>> referenced by z:\task_1623694336\src\intl\icu\source\common\udata.cpp:722
[task 2021-06-14T20:54:58.624Z] 6:06.51 >>> ......\config\external\icu\common\udata.obj:(struct UDataMemory * __cdecl openCommonData(char const *, int, enum UErrorCode *))
[task 2021-06-14T20:54:58.625Z] 6:06.51 lld-link: error: relocation against symbol in discarded section: icudt69_dat
[task 2021-06-14T20:54:58.625Z] 6:06.51 >>> referenced by z:\task_1623694336\src\intl\icu\source\common\udata.cpp:698
[task 2021-06-14T20:54:58.625Z] 6:06.51 >>> ......\config\external\icu\common\udata.obj:(struct UDataMemory * __cdecl openCommonData(char const *, int, enum UErrorCode *))
[task 2021-06-14T20:54:58.625Z] 6:06.51 >>> referenced by z:\task_1623694336\src\intl\icu\source\common\udata.cpp:722
[task 2021-06-14T20:54:58.625Z] 6:06.51 >>> ......\config\external\icu\common\udata.obj:(struct UDataMemory * __cdecl openCommonData(char const *, int, enum UErrorCode *))
[task 2021-06-14T20:54:58.625Z] 6:06.51 PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Later:
I've downloaded the patches from Phabricator and the ICU data file (icudt69l.dat) doesn't match what I have locally: It is an empty file on Phabricator! WTF.
Assignee | ||
Comment 14•3 years ago
•
|
||
Ah, okay. I think I understand what happened here: When the patches were backed out the first time, for some reason the ICU data file was replaced with an empty file: https://phabricator.services.mozilla.com/D116968?vs=450584&id=450646#change-c3mtSev48Kjf.
And when attempting to re-push the changes, the empty data file led to the errors which caused the second backout.
Assignee | ||
Comment 15•3 years ago
|
||
Hi Atila,
the backout in https://bugzilla.mozilla.org/show_bug.cgi?id=1714933#c9 overwrote a binary file (see comment #14). I don't know which tools/programs are used to perform backouts, but maybe you know who can be informed that there seems to be an issue in the backout process which can lead to deleting files.
Thanks,
André
Assignee | ||
Comment 17•3 years ago
|
||
Yes, thanks! That's exactly the issue observed here.
Comment 18•3 years ago
|
||
Comment 19•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7bc79fc0a919
https://hg.mozilla.org/mozilla-central/rev/c73fe793c9b2
https://hg.mozilla.org/mozilla-central/rev/ec885d83c826
https://hg.mozilla.org/mozilla-central/rev/ca2fccf42e3a
https://hg.mozilla.org/mozilla-central/rev/fc4205b8d565
https://hg.mozilla.org/mozilla-central/rev/920e59de0c38
https://hg.mozilla.org/mozilla-central/rev/a9def04a3236
https://hg.mozilla.org/mozilla-central/rev/fd06b2ce2393
Description
•