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>
It's used only for the ConfigurationWrapper singleton, so it's used
only the first time and then ignored. It also causes calls to
comphelper::getProcessComponentContext() for every single invocation
despite the value not being needed, and the calls may not be cheap
(it's ~5% CPU during ODS save because relatively frequent calls
to officecfg::Office::Common::Save::ODF::DefaultVersion::get()).
Change-Id: I02c17a1a9cb498aeef220ddd5a0bde5523cb0ffb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131056
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
... 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>
...as could be observed with ASan and ASAN_OPTIONS=strict_string_checks=1 during
e.g. UITest_conditional_format.
strtol supports leading spaces, sign, and "0x", but none of that appears to be
relevant here, so readInt32 doesn't support that.
Hdf::m_pItData was redundant and always pointed at m_aItData.data(), and has
been elided to make it more obvious that the places that used it, which now also
need to use m_aItData.size(), actually use m_aItData.
Change-Id: I3d4f625cd5836438271d7c1a8d2ae06f0a45a37c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119403
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
rtl::Reference now has a conversion operator to uno::Reference,
so look for places where we can simplify the code and use that.
Change-Id: Ic81db50d670bed5e875300577d4bf5f3599cc2c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110798
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This reverts commit 3ed9bba283. osl_Pos_Absolut
(include/osl/file.h) is part of the stable URE interface; it must not be changed.
Change-Id: I1f49923a9351e4be5aee39b10720d38b424feb9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110435
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
noticed something that wasn't being picked up, wrote some tests,
and found an unhandled case in Plugin::getParentFunctionDecl
Change-Id: I52b4ea273be6614e197392dfc4d6053bbc1704de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90141
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
"Find explicit casts from signed to unsigned integer in comparison against
unsigned integer, where the cast is presumably used to avoid warnings about
signed vs. unsigned comparisons, and could thus be replaced with
o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx)
o3tl::make_unsigned requires its argument to be non-negative, and there is a
chance that some original code like
static_cast<sal_uInt32>(n) >= c
used the explicit cast to actually force a (potentially negative) value of
sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the
cast to avoid a false "signed vs. unsigned comparison" warning in a case where
n is known to be non-negative. It appears that restricting this plugin to non-
equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=)
is a useful heuristic to avoid such false positives. The only remainging false
positive I found was 0288c8ffec "Rephrase cast
from sal_Int32 to sal_uInt32".
But which of course does not mean that there were no further false positivies
that I missed. So this commit may accidentally introduce some false hits of the
assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan
--enable-dbgutil) `make check && make screenshot`.
It is by design that o3tl::make_unsigned only accepts signed integer parameter
types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses
which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in
include/oox/helper/helper.hxx is used with both signed and unsigned types, so
needs a little oox::detail::make_unsigned helper function for now. (The
ultimate fix being to get rid of the macro in the first place.)
Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Stephan Bergmann