Age | Commit message (Collapse) | Author |
|
The option /Zc:wchar_t- prevented to use wchar_t as a built-in type
according to the C++ standard. In Visual C++ 6.0 and earlier, wchar_t
was not implemented as a built-in type, but was declared in wchar.h as
a typedef for unsigned short. Now, years later after the end of life
this outdated toolchain, there is no reason not to use native type.
The only issue could be the ABI compatibility. But on a quick look at
least, it looks like none of the mangled C++ symbols in the stable URE
interface actually depend on wchar_t.
We forgot to get rid of /Zc:wchar_t- in 5.1. Do that for LibreOffice
5.2, though.
Change-Id: I8d6b380660859efa44c83c830734978d31d756a0
Reviewed-on: https://gerrit.libreoffice.org/22589
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Patch has been upstreamed with
https://ssl.icu-project.org/trac/ticket/12504
Change-Id: I1f3ddad87a2a6568ced3f9d2b2df3e0af0ee18aa
Reviewed-on: https://gerrit.libreoffice.org/24117
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Martin Hosken <martin_hosken@sil.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
This does not apply patches
external/icu/khmerbreakengine.patch
external/icu/khmerdict.dict
anymore, as the khmerbreakengine.patch failed to apply with several
hunks of which one was 16k. Asking the patch contributor to follow-up on
this.
Change-Id: I78d4371d04a7b03417d402a222bcd384f02a619e
Reviewed-on: https://gerrit.libreoffice.org/24067
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Iec71ad4918cd333f0a44d372017ecee300e3aca9
Reviewed-on: https://gerrit.libreoffice.org/20748
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Martin Hosken <martin_hosken@sil.org>
|
|
Change-Id: I8e75b0ab2439592316fc0d871280a438e3ae2f1c
|
|
Change-Id: Icc3d66c16fca95aa890aee6c67c84674fef878fc
|
|
Change-Id: If5924054b53fd2b5acf2ec903cd1acf710cc2ef1
|
|
Change-Id: Iec2806dfa416bcbfa63eed2985c74c7a2ea897ea
Reviewed-on: https://gerrit.libreoffice.org/16759
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I15f8e960f253db3f13f68bb2da84f0191d888f5b
|
|
Change-Id: Ib287799906e234ce795a0f9ded5cdeebcdffba4e
|
|
Backported from
http://bugs.icu-project.org/trac/changeset/36724
http://bugs.icu-project.org/trac/changeset/36727
http://bugs.icu-project.org/trac/changeset/36801
Change-Id: Idd85c3344e3ef86e390341038f53ad2a398b3fa3
|
|
Change-Id: Ia972d7364b5acfbafd9df5b07f4fb8bd6efbab5f
|
|
Change-Id: I4d32ac386ff8b69bee4319e673769917045d9450
Reviewed-on: https://gerrit.libreoffice.org/13547
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3bd37f8468c95a29ab3385dbc3ae825b76d8d3df
|
|
Change-Id: I9325bb28eb267b023f628e24fea216ad580759e9
|
|
Change-Id: I67d0b4b0c39c62646c7a0ae7152c7ca256680c38
|
|
Change-Id: I0c052cbcfe375bd1279c2235b53c909920e2e779
|
|
Change-Id: I5dd63fa41c1568e8bf2d120cc0de5d2c44dd789c
|
|
Change-Id: I41ec24a02867ba3c5bf4f39b5d79bf6a3254ad0d
|
|
plus further work in i18npool to make that build
adapt i18npool to ICU 53 upgrade, fdo#77071
Korean charset collator can't be built from ko_charset.txt because of
"The runtime code decomposes Hangul syllables on the fly, with recursive
processing but without making the Jamo pieces visible for matching. It
does not work with certain types of contextual mappings."
"While handling a Hangul syllable, contractions starting with Jamo L or
V would not see the following Jamo of that syllable." (this is where we
bail out already with the first syllable of ko_charset.txt)
Another condition to fail is described as "A contraction ending with
Jamo L or L+V would require generating Hangul syllables in
addTailComposites() (588 for a Jamo L), or decomposing a following
Hangul syllable on the fly, during contraction matching."
Excluded the file from the build for ICU >=53 and hope that ICU in the
mean time handles Korean collation correctly.
Additionally, ICU 53 took ages (if it would had finished at all) to
build the collator from zh_TW_charset.txt because of the \u#### escaped
notation. Converted the file's content to characters using
http://www.rishida.net/tools/conversion/
Change-Id: I64213214b4870e7077f72b95fee1ddc9782c2b21
Reviewed-on: https://gerrit.libreoffice.org/9204
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I99c62b08b84d2d8afafd391257ab7b8b2d887fac
|
|
Change-Id: I25e4b630c9029749cc459c0b65da287d6f0ba95e
Reviewed-on: https://gerrit.libreoffice.org/6666
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I9d8191848b093240f79207446afb13ca6fd708e4
Reviewed-on: https://gerrit.libreoffice.org/6309
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|