and
cid#1660117 Variable copied when it could be moved
cid#1659985 Variable copied when it could be moved
cid#1659983 Variable copied when it could be moved
cid#1659982 Variable copied when it could be moved
cid#1659973 Variable copied when it could be moved
cid#1659956 Variable copied when it could be moved
cid#1659955 Variable copied when it could be moved
Change-Id: Icc0f2f4a37fa8eb4c874dfd842650067c186466b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189255
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and
cid#1660326 Variable copied when it could be moved
cid#1660325 Variable copied when it could be moved
cid#1660324 Variable copied when it could be moved
cid#1660321 Variable copied when it could be moved
cid#1660320 Variable copied when it could be moved
cid#1660316 Variable copied when it could be moved
cid#1660313 Variable copied when it could be moved
cid#1660307 Variable copied when it could be moved
Change-Id: I9fe4fa56693f8e3a1efd47294ecb7e0e5588b9b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188851
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
what I'm really after is some vexating not-reproducible oss-fuzz msan
warnings when using libxml2 in the fodt2pdf fuzzer. So lets upgrade
libxml2 to the latest, which requires bumping libxslt, and then requires
a newer liblangtag because of no longer implicit includes that it
depended on.
xmlKeepBlanksDefaultValue and xmlSubstituteEntitiesDefault are
deprecated, we should get around to updating those uses
Change-Id: I8fda0dffda0a7ea65407d246a3121875cb8ad4a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161598
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Our embedded clucene by default write a random current-time
millisecond value into version fields, in an attempt to
randomise. Clearly this is not needed for our static help, and it also
prevents builds from being reproducible.
Change-Id: I011388b5bc72b5d86bc1900f5439036ede60c020
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158845
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Seen in a fedora:40 container, using --with-system-libcmis,
--with-system-liblangtag and --with-system-xmlsec.
Change-Id: I9d748d3dc0b70dbfdfcb6b99c9ce8440bda6f326
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159980
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
E.g., a path like
C:\lo\src\build\instdir\program\..\program\..\user\extensions\bundled\registry\com.sun.star.comp.deployment.help.PackageRegistryBackend\lu149121qyy8a.tmp\da\help.idxl
would become 22 characters shorter:
C:\lo\src\build\instdir\user\extensions\bundled\registry\com.sun.star.comp.deployment.help.PackageRegistryBackend\lu149121qyy8a.tmp\da\help.idxl
Change-Id: Id6d397fdd7a1771225eef2e7e49ddb80802685b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156947
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Lucene does not accept Unicode paths; it uses thread encoding. On
Windows, that makes it fail for any path that contains characters
not representable in ACP. Using short path name tries to workaround
that when first attempt has failed.
Since Windows 10 build 17134, the UCRT supports using a UTF-8 code
page: see
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale.
This has benefit of using Unicode, but I hesitate using it, since I
am not sure if setting the locale globally to UTF8 is a good idea
(what side effects may it have on other external libraries or our
use of CRT functions, when thread encoding differs from C locale?),
and if only setting it at object creation, it would crash later,
when attempting to access the stored Unicode path with restored old
locale.
Change-Id: I6a3a5a84ba54d8046ec011989289c9c7d5fa5c92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108484
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...with recent Clang 10 trunk:
> helpcompiler/source/HelpIndexer.cxx:119:71: error: bitwise operation between different enumeration types ('lucene::document::Field::Store' and 'lucene::document::Field::Index') is deprecated [-Werror,-Wdeprecated-enum-enum-conversion]
> doc->add(*_CLNEW Field(_T("path"), aPath.data(), Field::STORE_YES | Field::INDEX_UNTOKENIZED));
> ~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~
where the Field constructor in
workdir/UnpackedTarball/clucene/src/core/CLucene/document/Field.h has an "int
_config" parameter that is apparently intended to take a mix of Store (bit
values 1, 2, 4) and Index (bit values 16, 32, 64, 128) flags.
Change-Id: Ie080e44bf820cb776bc61ac22cf73f5437d8c5dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85972
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This branch is only in use for the build-tool mode, so doesn't affect extension
help.
I can find no difference in our output help dir with these removed vs in place
so lets remove it.
Change-Id: If8511b6cb74f1af136a71ab39a7a5759d50c43eb
Reviewed-on: https://gerrit.libreoffice.org/83480
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
doesn't seem to make any sense, maybe it did in some dmake-era
dependency problem when building our help content ?
Change-Id: Id964ad73249ef33ba0102fb7d2d853b2719e3814
Reviewed-on: https://gerrit.libreoffice.org/83466
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
...following up on 314f15bff0 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It started out as a wrapper around character literals, but has by now become a
wrapper around arbitrary single characters. Besides updating the documentation,
this change is a mechanical
for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done
Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f
Reviewed-on: https://gerrit.libreoffice.org/80892
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Andrea Gelmini