...as emsdk 5.0.3 deprecated the predefined EMSCRIPTEN macro (see
<https://github.com/emscripten-core/emscripten/commit/506052bd8b4e23ded7f2351c62ca3b24d40c8cf3>
"Warn about usage of deprecated EMSCRIPTEN macro. NFC (#26381)"), causing
failures like
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:29:
> In file included from include/sfx2/viewsh.hxx:35:
> In file included from include/editeng/outliner.hxx:32:
> In file included from include/tools/color.hxx:26:
> include/osl/endian.h:66:15: error: macro 'EMSCRIPTEN' has been marked as deprecated: use __EMSCRIPTEN__ instead [-Werror,-Wdeprecated-pragma]
> 66 | #elif defined EMSCRIPTEN
> | ^
> /home/sberg/emsdk/5.0.4/emsdk/emscripten/main/cache/sysroot/include/emscripten/emscripten.h:35:66: note: macro marked 'deprecated' here
> 35 | #pragma clang deprecated(EMSCRIPTEN, "use __EMSCRIPTEN__ instead")
> | ^
To avoid confusion, also suppress the -D$(OS) in
solenv/gbuild/platform/unxgcc.mk that would unnecessarily keep defining
EMSCRIPTEN.
Change-Id: Ic1f187cf1c6417cd95d4092e9cea01a665bd1b2f
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/34
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 50291c2ed83bdb49bb827a4a12905d94b8c42035)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205167
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
we allocate an awful lot of temporary OUString while looking up translation strings.
Add some API to LanguageTag to reduce this by using a common OStringBuffer.
Reduces peak memory usage from 420M to 283M
Change-Id: Ie55267631f2178e3a6590eebf5876c963a4cda69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198197
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
These changes improve const-correctness and reduce the need for const_cast
usage.
Change-Id: I1275edfbc0ca5d49a5e8339d1ed11148f6decd1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174701
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Most of these don't use boost themselves, nor do they need
it transitively since the use of boost::optional was removed
Change-Id: Ic9dee1c4e160b313ec5b91677b02ffdea6c5779d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164440
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
A local const static still needs a constructor the first time, and
the short atomic checks if it is initialized every time the control
flow crosses it.
A constexpr static does not need all of that.
Change-Id: I9c4cc082c7dfafcf6197dbe5a697ab27fdef2711
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162952
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
improve the check by checking for methods that exclude
using string_view, rather than checking for methods that
__can__ use string_view, which leads to exposing
some holes in our o3tl/string_view.hxx coverage.
Change-Id: Ic9dd60441c671f502692f9cd2a1bb67301c4b960
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150277
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Necessary for {es-419} and the like that are predefined language
tags with known LCID mappings.
Change-Id: I46491842fc11836a55cd56327d4f955952c026f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147182
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
This happened for known tags like es-419 but unhandled in
simpleExtract(), which actually should be implemented as now a few
are mapped as known tags. Prevent adding such empty string.
For that, adjust configmgr/qa/unit/test.cxx to test for the
expected "en-US" instead of "default".
Change-Id: I05f8e35a9d88b42d45e1f2a90aecec5f4470cc79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147135
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
These are pulled in by either our own bundled extension
dictionaries (es-*, ca-*), or hunspell dictionary (en-AG), but
have no language listbox entry (and don't need one until someone
insists) thus are generated.
So if selected and in case stored in binary MS file formats ensure
a stable back-and-forth conversion. The on-the-fly 0x7e1, 0x7e2,
... are generated arbitrarily in order as encountered.
Change-Id: I0dc72bf1301b26d5b82e1b271c58fc77c82eea0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145161
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
First, the LANGUAGE_SPANISH_LATIN_AMERICA 0xE40A is not a MS
system LCID, it is Spanish 0x00a with sublanguage 0x39 => user
defined (in the range 0x20 to 0x3f). Meanwhile MS reserved 0x580A
for {es-419}, so obsolete the legacy 0xE40A definition and replace
with 0x580A when encountered.
Second, due to the legacy plain {es} mapping being present, an
encountered 'es' (from our bundled dictionary extension) got
mapped to 0xE40A instead of 0xA and thus was added to the
character language listbox (that otherwise suppresses LCIDs
without sublanguage), resulting in a "Spanish {es}" entry.
Besides, it's currently not clear how to actually proceed with
such dictionary situation when, for example, both 'es-ES' and 'es'
dictionaries are present and the 'es' dictionary apparently is
meant as base and contains entries the 'es-ES' does not or 'es-ES'
overrides entries. It might be it's handled half-way in
linguistics, but maybe not even that, I didn't investigate.
Change-Id: Id859731ba5efa65d4a6de429b7f52027aa69327c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145093
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
And not just Android. Hardcoded to return "/instdir" to match what is
in the emscripten_fs_image.
Change-Id: I26d4ec5e02ec9900e35ca47f1565a13ad2b723b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144849
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Basically copies pt_PT.xml but replaces translated with
untranslated keywords (AA,AAAA => YY,YYYY), hence no ref="pt_PT"
for LC_FORMAT (and LC_CTYPE).
Also use sort-formats.awk -v group=1 to sort FormatElement by usage
group and formatIndex as those went quite wild over time..
Change-Id: Iececac0ebdd0317fd14ab65f32c08501f3ce32c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143398
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
A tag with script could be added for which we don't have locale
data but for the same language in another script. Do not fall back
to that.
With that the share/autocorr/acor_zh-{CN,TW}.dat files created
additional Asian language listbox entries
"Chinese (Simplified, China) {zh-Hans-CN}"
"Chinese (Traditional, Taiwan) {zh-Hant-TW}"
because those are the canonicalized language tags.
Prefer the known legacy zh-CN and zh-TW tags instead.
Could also had happened with any document import.
Which again revealed a flaw in the handling of mapping overrides
where converting from a LanguageType LCID to Locale could yield a
different mapping than from BCP47 to LCID, which in the case of
a fallback for locale data lead to odd side effects.
Change-Id: I1e2aaa8e9f99b6b3bc2c9a661215cb00bddd33d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140939
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Revert to long as originally used in commit e81359a9a3:
"added registerImpl() re-entered warning" and then apparently
accidentally broken in the mass conversion commit
e25fd7782a: "long->tools::Long in hwpfilter..oox".
Change-Id: I39c983ddec83c84953bc3db167793944c671894b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135714
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Caolán McNamara