With this new version, the build started to fail with
error: ‘XML_Size XML_GetCurrentColumnNumber(XML_Parser)’ is deprecated: please use XML_GetCurrentColumnNumber64 instead [-Werror=deprecated-declarations]
so we need to check the expat version in case the system expat
is older than 2.9
Also add 0001-fix-XML_GE-is-not-defined-evaluates-to-0-Werror-unde.patch
to fix
error: "XML_GE" is not defined, evaluates to 0 [-Werror=undef]
1087 | # if XML_GE == 1
| ^~~~~~
cc1plus: all warnings being treated as errors
Change-Id: If4f1d652941b7766ed94b65a6eaa018f37c89387
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211867
Tested-by: Jenkins
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Relocate the whole solver component out of the standalone sccomp module
and into sc. This moves the SolverComponent base class, the CoinMP and
Swarm solvers, the differential evolution and particle swarm headers, the
UNO service registration, the scc string resource, and the two unit tests.
The now-empty sccomp module is removed.
The solvers are Calc specific. Moving them inside sc is the first step
toward letting them work directly with ScDocument, and eventually clone a
document or its sheets so trial calculations can run in parallel. That
direct access is only possible from inside sc, so the relocation has to
come first.
This is a pure relocation with no behaviour change. The translation domain
stays "scc" and its polocation still points at "sccomp", so the existing
translations keep loading unchanged. Re-homing the scc translation domain
into sc is left as a follow-up.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I5b972daae4c51f04ca394fc9a92f89ac0c4dd599
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3832
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 7f1bea8723761f97c053f2e7e46aab7081b1bb21)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208080
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
…by manually specifying it as part of the --with-lang switches
surprisingly enough this wasn't just a matter of adding the qtz language
code to the corresponging language list variables used by make, but also
was directly coupled to the ENABLE_RELEASE_BUILD environment variable
for some parts.
Change-Id: Icc985d9e7428ab932de09bd31e86e5ea7551f6fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192874
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
Use a common implementation; do not create a temporary OString,
where we only need a view of existing std::string.
Change-Id: I1ba29d2600ac03279a19dbf2919ac80d3f8a620c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187945
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
* Check the number of opening and closing parentheses,
brackets and square brackets are the same
* Check {&DialogHeading} and {&DialogDefaultBold} are
at the beginning of the string.
the translation here
* Check [ProductName] is kept. It's just a warning
so pocheck doesn't remove the translation here
Change-Id: Ica06e22ec547375b84ed829da12178b5976b357c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187554
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
V1024 The 'aIfstream' stream is checked for EOF before reading from it, but is not checked after reading. Potential use of invalid data.
Change-Id: I253513c47ec1482882bbfb1c6e32e25c15ace99c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175475
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
V1024 The 'aInput' stream is checked for EOF before reading from it, but is not checked after reading. Potential use of invalid data.
Change-Id: Ie0c6d1928dad804b21d3c9920cc1de8035ea0367
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175476
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
will be included when using --with-lang=ALL in non-release configuration
(i.e. tinderbox provided daily builds), but not when using
--enable-release-build.
Change the way how configure fetches the list of all supported languages
from a fancy sed call to running make with a dummy-recipe.
Change-Id: I8bbea5fd95d37eac5bbce2e55ae34830b0ab4ebb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168334
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
For similar code sequences that can be improved.
Also move containsComment from collapseif plugin code to
plugin.cxx so we can use it from stringadd.
Change-Id: Ie07d9aedf2c31cb0b2080e1b8584294d7046a8e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149217
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which caused `make translations` fail for me with
> [POT] pot.done
> dyld[96290]: Library not loaded: @__VIA_LIBRARY_PATH__/libuno_sal.dylib.3
> Referenced from: <CD4F28D6-E3BE-3126-B861-C90BF3E14492> .../workdir/LinkTarget/Executable/cfgex
> Reason: tried: '/System/Volumes/Preboot/Cryptexes/OS@__VIA_LIBRARY_PATH__/libuno_sal.dylib.3' (no such file), '/usr/local/lib/libuno_sal.dylib.3' (no such file), '/usr/lib/libuno_sal.dylib.3' (no such file, not in dyld cache)
> Error: Failed to execute .../workdir/LinkTarget/Executable/cfgex -i .../connectivity/registry/ado/org/openoffice/Office/DataAccess/Drivers.xcu -o .../workdir//pot/connectivity/registry/ado/org/openoffice/Office/DataAccess.pot
(This is the opposite case to 17cfd43e28 "Avoid
external processes picking up instdir/program/libxml2.so.2". Here, the
executables called from Executable_localize are LO-internal executables that
need the libraries in instdir/. There, the scripts called from
Executable_localize in turn only call external tools that shall not accidentally
pick up LO-internal libraries from instdir/.)
Change-Id: Ib1aa240ee47a21d14ec0463fee85bebe82453cee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143118
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which is a problem in ASan builds, as seen with a failing `make check`:
> xgettext: symbol lookup error: .../instdir/program/libxml2.so.2: undefined symbol: __asan_init
> xgettext: symbol lookup error: .../instdir/program/libxml2.so.2: undefined symbol: __asan_init
> xgettext: symbol lookup error: .../instdir/program/libxml2.so.2: undefined symbol: __asan_init
> xgettext: symbol lookup error: .../instdir/program/libxml2.so.2: undefined symbol: __asan_init
> xgettext: symbol lookup error: .../instdir/program/libxml2.so.2: undefined symbol: __asan_init
> Traceback (most recent call last):
> File ".../solenv/bin/uiex", line 25, in <module>
> input = check_output(["xgettext", "--add-comments", "--no-wrap", ifile, "-o", "-"], encoding="UTF-8")
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File "/usr/lib64/python3.11/subprocess.py", line 465, in check_output
> return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File "/usr/lib64/python3.11/subprocess.py", line 569, in run
> raise CalledProcessError(retcode, process.args,
> subprocess.CalledProcessError: Command '['xgettext', '--add-comments', '--no-wrap', '.../basctl/uiconfig/basicide/ui/basicmacrodialog.ui', '-o', '-']' returned non-zero exit status 127.
> Error: Failed to execute .../solenv/bin/uiex -i .../basctl/uiconfig/basicide/ui/basicmacrodialog.ui -o .../workdir//pot/basctl/messages.pot
The solution is similar to e854abe076 "Avoid
external processes picking up instdir/program/libnspr4.so" used in various
tests. And as Executable_localize appears to only be called in that one place
in the recipe of `make translations`, for simplicity make the library path
override a required fourth argument for that executable.
Change-Id: Ia6326ac0bb12ea75a8b3df51f7fbf12b88aca634
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142999
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
This is apparently some very old, very poor XML parsing code full of
questionable design decisions. The silliness of pushing onto the opened-element
stack also entities that don't have a closing tag (but which cannot easily be
changed, see the added comment about CfgStack::GetAccessPath) caused consistent
memory leaks when Executable_cfgex is executed during the build. While those
leaks are harmless, they might cause people to nevertheless try to clean them up
in various ways (see the abandoned
<https://gerrit.libreoffice.org/c/core/+/142718> "asan: fix leak in
ExecuteAnalyzedToken/Push"), so just clean up those broken-by-design excess
aStack elements.
Change-Id: I849109906c6b102d9aa90300c2bada360c727d4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143001
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
> l10ntools/source/xmlparse.cxx:491:51: runtime error: downcast of address 0x603000000610 which does not point to an object of type 'XMLParentNode'
> 0x603000000610: note: object is of type 'XMLDefault'
> 00 00 00 00 30 44 a7 dd a0 55 00 00 00 05 10 6e a4 7f 00 00 80 00 00 00 60 60 00 00 00 00 00 00
> ^~~~~~~~~~~~~~~~~~~~~~~
> vptr for 'XMLDefault'
> #0 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:491:51
> #1 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:481:9
> #2 in HelpParser::CreatePO(rtl::OString const&, rtl::OString const&, XMLFile*, std::basic_string_view<char, std::char_traits<char>>) at l10ntools/source/helpmerge.cxx:91:20
> #3 in sal_main_with_args(int, char**) at l10ntools/source/helpex.cxx:124:17
> #4 in main at l10ntools/source/helpex.cxx:47:1
and
> l10ntools/source/xmlparse.cxx:523:44: runtime error: downcast of address 0x6030000007c0 which does not point to an object of type 'XMLParentNode'
> 0x6030000007c0: note: object is of type 'XMLData'
> 00 00 00 00 e0 53 d5 c0 46 56 00 00 d0 00 00 00 40 60 00 00 f0 07 00 00 30 60 00 00 00 00 00 00
> ^~~~~~~~~~~~~~~~~~~~~~~
> vptr for 'XMLData'
> #0 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:523:44
> #1 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:492:80
> #2 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:481:9
> #3 in HelpParser::CreatePO(rtl::OString const&, rtl::OString const&, XMLFile*, std::basic_string_view<char, std::char_traits<char>>) at l10ntools/source/helpmerge.cxx:91:20
> #4 in sal_main_with_args(int, char**) at l10ntools/source/helpex.cxx:124:17
> #5 in main at l10ntools/source/helpex.cxx:47:1
and
> l10ntools/source/xmlparse.cxx:526:48: runtime error: downcast of address 0x603000000820 which does not point to an object of type 'XMLParentNode'
> 0x603000000820: note: object is of type 'XMLComment'
> 00 00 00 00 28 06 92 a9 17 56 00 00 d0 00 00 00 40 60 00 00 40 00 00 00 20 61 00 00 00 00 00 00
> ^~~~~~~~~~~~~~~~~~~~~~~
> vptr for 'XMLComment'
> #0 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:523:44
> #1 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:492:80
> #2 in XMLFile::CheckExportStatus(XMLParentNode*) at l10ntools/source/xmlparse.cxx:481:9
> #3 in HelpParser::CreatePO(rtl::OString const&, rtl::OString const&, XMLFile*, std::basic_string_view<char, std::char_traits<char>>) at l10ntools/source/helpmerge.cxx:91:20
> #4 in sal_main_with_args(int, char**) at l10ntools/source/helpex.cxx:124:17
> #5 in main at l10ntools/source/helpex.cxx:47:1
Change-Id: I1e2c6bf802aa03b5b1eb21532e98fa22d966e683
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143000
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
After 6d6a143913 "Address some of the sprintf in
vcl/source/fontsubset/cff.cxx", --with-latest-c++ builds that pick up a C++23
compiler that implements
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1:
Simpler implicit move" started to fail with something like
> vcl/source/fontsubset/cff.cxx:2061:16: error: no viable conversion from returned value of type 'char[64]' to function return type 'OString'
> return aDefaultGlyphName;
> ^~~~~~~~~~~~~~~~~
[...]
> include/rtl/string.hxx:313:5: note: candidate constructor [with T = char[64]] not viable: expects an lvalue for 1st argument
> OString( T& value, typename libreoffice_internal::NonConstCharArrayDetector< T, libreoffice_internal::Dummy >::Type = libreoffice_internal::Dummy() )
> ^
etc. So I figured there should be something better than
433ab39b21 "Adapt implicit OString return value
construction to C++23 P2266R1" (which this commit reverts, modulo its conflicts
in comphelper/source/xml/xmltools.cxx and
sc/source/filter/xcl97/XclExpChangeTrack.cxx) to address the underlying issue in
a way that keeps code that works up to C++20 also working in C++23.
(The fix is only relevant for non-explicit constructors that involve
NonConstCharArrayDetector and non-const lvalue references, not for other
functions involving those. OUString has a similar constructor but which is
explicit, and OUStringBuffer doesn't have any similar constructors at all, so
this only affects OString and OStringBuffer constructors.)
Change-Id: I31cf16b9507899f5999243f8467dfa24bc94c5ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142455
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
in the conversion in
commit 74957c7d2f
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Apr 13 13:54:22 2022 +0200
use more string_view in l10ntools
where the prior code might have been relying on the -1 returned by
indexOf and lastIndexOd
Change-Id: Ief5dedccbaf4e14e5f59aa3c2f7481ff0bb7e2e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133027
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for call sequences that can use string_view and the new o3tl
functions in o3tl/string_view.hxx
Also add a few more wrappers to said #include file
Change-Id: I05d8752cc67a7b55b0b57e8eed803bd06bfcd9ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
since we now have o3tl versions of those that work on
string_view.
Also improve those o3tl functions to support both string_view
and u16string_view
Change-Id: Iacab2996becec62aa78a5597c52d983bb784749a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132755
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Xisco Fauli