...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>
...now that warning about O[U]String vars that could be O[U]StringLiteral is no
longer useful
Change-Id: I389e72038171f28482049b41f6224257dd11f452
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157992
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
To remove unneeded using declarations.
Via the simple script:
for i in $(find $dirname -name "*cxx" -o -name "*hxx" ); do
clang-tidy-12 --checks="-*,misc-unused-using-decls" "$i";
done
Change-Id: Iccae38de41c809b39345ec6b31c9f6346e620f53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150611
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
And simplify the latter, to always use "CDATA" type (as the former did).
"CDATA" was used in all cases but one, where an empty string was used.
Change-Id: I1b3bfae40e29628e4094d9a6e58a69a66865874c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145526
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
so we don't have to pass in the size of the string literal.
This is mostly a preparatory change, to make an another
patch of mine less noisy.
Change-Id: Idafcd68586b8b465e63dc89e4a4180d2e70ac3a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125080
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... to avoid hidden cost of multiple COW checks, because they
call getArray() internally.
This obsoletes [loplugin:sequenceloop].
Also rename toNonConstRange to asNonConstRange, to reflect that
the result is a view of the sequence, not an independent object.
TODO: also drop non-const operator[], but introduce operator[]
in SequenceRange.
Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The scenarios are:
1. Calling sequence's begin() and end() in pairs to pass to algorithms
(both calls use getArray(), which does the COW checks)
2. In addition to #1, calling end() again when checking result of find
algorithms, and/or begin() to calculate result's distance
3. Using non-const sequences in range-based for loops, which internally
do #1
4. Assigning sequence to another sequence variable, and then modifying
one of them
In many cases, the sequences could be made const, or treated as const
for the purposes of the algorithms (using std::as_const, std::cbegin,
and std::cend). Where algorithm modifies the sequence, it was changed
to only call getArray() once. For that, css::uno::toNonConstRange was
introduced, which returns a struct (sublclass of std::pair) with two
iterators [begin, end], that are calculated using one call to begin()
and one call to getLength().
To handle #4, css::uno::Sequence::swap was introduced, that swaps the
internal pointer to uno_Sequence. So when a local Sequence variable
should be assigned to another variable, and the latter will be modified
further, it's now possible to use swap instead, so the two sequences
are kept independent.
The modified places were found by temporarily removing non-const end().
Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Remove overloads taking const char* which were not needed, because
every their use eventually took a string literal convertible to
OUString directly.
Many other literals were converted to OUStringLiterals.
Change-Id: Ia1e742a8087776cd20bf5094dc415dafd9a8834a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123155
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
noting that XMLTokenEnum was already being treated as being limited to
32-bits, we bitmask it together with namespaces
Change-Id: Ic48f2a662452d1b8e022078d31a723d2ac65aef0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121707
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
In sc/qa/unit/ucalc_formula.cxx, dropping the capture-default from the
lExpectedinF lambda revealed that MSVC in C++17 mode (i.e., when building
without --with-latest-c++) requires ROW_RANGE (a local const int variable from
the enclosing TestFormula::testTdf97369) to be captured, even though all uses of
that variable within the lambda body are constant expressions. That is still
true at least for the latest Visual Studio 2019 version 16.11.1. (This is not
an issue for the lExpectedinH and lExpectedinI lambdas a few lines further down,
as they, in addition to using that ROW_RANGE, also use the local const double
variables SHIFT1 and SHIFT2, whose uses are not constant expressions, so
they are implicitly captured and loplugin:unusedcapturedefault does not suggest
dropping those lambdas' capture-defaults in the first place.)
Change-Id: Iee7efb485187cbe8eba6a2d470afca4993eb1816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120693
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for
operator call arguments. (The "rather than copy, pass subView()" diagnostic is
already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly
for operator call arguments.)
(And many call sites don't even require an explicit [u16]string_view, esp. with
the recent ad48b2b02f "Optimized OString operator
+= overloads". Just some test code in sal/qa/ that explicitly tests the
O[U]String functionality had to be excluded.)
Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
LO without commit 519d96fd8b makes a mess
when storing form documents it has loaded from ODF 1.3 documents: the
XML parts are stored as ODF 1.2, but the storage (and therefore manifest
entry) keeps version 1.3.
To avoid this, store form documents as ODF 1.2 extended by default.
Unfortunately a bunch of ODF export code accesses the global
SvtSaveOptions variable; with this version override, only
SvXMLExport::getSaneDefaultVersion() must be used.
Change-Id: I5fa8e286f5103c578ed0d93da07a8a6cbe2f0ddd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115357
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
which can use the more efficient *StringConcat
Also fix a crash in stringview plugin which
started happening while I working on this.
Change-Id: I91a5b9b7707d1594d27d80b73930f5afac8ae608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
regression due to a combination of
commit 3de38e9556
Date: Tue Nov 10 19:20:06 2020 +0200
use fastparser in forms
and
commit 3d00847709
Date: Fri Dec 4 16:14:16 2020 +0200
fastparser in a couple of random places
The first one introduced the bug, due to the fallback
paths from fast to slowparser, things kept working, until
the second one removed the fallback.
Change-Id: I1aaae902eda2aaf8f5151404ddb3577f4582757d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111101
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Gabor Kelemen