...as seen at least with --disable-optimized against recent GCC 16 trunk,
> In file included from workdir/UnoApiHeadersTarget/udkapi/comprehensive/com/sun/star/lang/XTypeProvider.hpp:11,
> from include/cppuhelper/implbase.hxx:28,
> from cppuhelper/source/component_context.cxx:30:
> include/com/sun/star/uno/Sequence.hxx: In constructor ‘com::sun::star::uno::Sequence< <template-parameter-1-1> >::Sequence(sal_Int32) [with E = rtl::OUString]’:
> include/com/sun/star/uno/Sequence.hxx:97:55: error: ‘<unknown>’ may be used uninitialized [-Werror=maybe-uninitialized]
> 97 | const Type & rType = ::cppu::getTypeFavourUnsigned( this );
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
> include/com/sun/star/uno/Sequence.hxx:326:1: note: by argument 1 of type ‘const com::sun::star::uno::Sequence<rtl::OUString>*’ to ‘const com::sun::star::uno::Type& cppu::getTypeFavourUnsigned(const com::sun::star::uno::Sequence<T>*) [with T = rtl::OUString]’ declared here
> 326 | getTypeFavourUnsigned(
> | ^~~~~~~~~~~~~~~~~~~~~
> include/com/sun/star/uno/Sequence.hxx: In constructor ‘com::sun::star::uno::Sequence< <template-parameter-1-1> >::Sequence() [with E = com::sun::star::uno::Any]’:
> include/com/sun/star/uno/Sequence.hxx:60:55: error: ‘<unknown>’ may be used uninitialized [-Werror=maybe-uninitialized]
> 60 | const Type & rType = ::cppu::getTypeFavourUnsigned( this );
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
> include/com/sun/star/uno/Sequence.hxx:326:1: note: by argument 1 of type ‘const com::sun::star::uno::Sequence<com::sun::star::uno::Any>*’ to ‘const com::sun::star::uno::Type& cppu::getTypeFavourUnsigned(const com::sun::star::uno::Sequence<T>*) [with T = com::sun::star::uno::Any]’ declared here
> 326 | getTypeFavourUnsigned(
> | ^~~~~~~~~~~~~~~~~~~~~
> include/com/sun/star/uno/Sequence.hxx: In constructor ‘com::sun::star::uno::Sequence< <template-parameter-1-1> >::Sequence() [with E = signed char]’:
> include/com/sun/star/uno/Sequence.hxx:60:55: error: ‘<unknown>’ may be used uninitialized [-Werror=maybe-uninitialized]
> 60 | const Type & rType = ::cppu::getTypeFavourUnsigned( this );
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
> include/com/sun/star/uno/Sequence.hxx:326:1: note: by argument 1 of type ‘const com::sun::star::uno::Sequence<signed char>*’ to ‘const com::sun::star::uno::Type& cppu::getTypeFavourUnsigned(const com::sun::star::uno::Sequence<T>*) [with T = signed char]’ declared here
> 326 | getTypeFavourUnsigned(
> | ^~~~~~~~~~~~~~~~~~~~~
Change-Id: I700c8a9f2116ff9f017d50b161794bfe06e74e1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
See commit 16a0b42a4f, which fixed a
code doing that accidentally, which wasn't caught by compiler, and
caused a crash at runtime.
This will prevent such code from compiling.
Change-Id: Ibf6fdc118542fb4c7f941a928bec113bafab047e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191597
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
rtl::Reference, uno::Any and rtl::O[U]String
where we have implemented move ctors to take let the compiler take
advantage of any little optimization possibility that it can take
but where the potential optimization probably doesn't outweigh
enforcing dusting error-prone std::move all over every case where
the compiler doesn't/can't use the move ctor but could.
Change-Id: Icf184d96d3278a1740a76c7eb1150e60392351ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162337
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
to avoid some unnecessary construction - we hit this path when going
through the comphelper makeProperty functions sometimes
Change-Id: Idbc4550c9ca26d4a940397d6fe038db5c342867f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151689
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Similar to commit f3ffdc1a5f
(Introduce non-static query() and queryThrow() to css::uno::Reference,
2023-03-23), this adds a syntactic sugar for css::uno::Reference ctors:
css::uno::Reference<css::SomeNamespace::SomeInterface> xSomeInterface(anAny, css::uno::UNO_QUERY);
would become
auto xSomeInterface(anAny.query<css::SomeNamespace::SomeInterface>());
and
css::uno::Reference<css::SomeNamespace::SomeInterface> xSomeInterface(anAny, css::uno::UNO_QUERY_THROW);
would become
auto xSomeInterface(anAny.queryThrow<css::SomeNamespace::SomeInterface>());
Change-Id: I06f8d97fe200a7dd03ecc965a431eb54b10a3c91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149549
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
As a syntactic sugar for the respective ctors:
css::uno::Reference<css::SomeNamespace::SomeInterface> xSomeInterface(xAnotherInterface, css::uno::UNO_QUERY);
would become
auto xSomeInterface(xAnotherInterface.query<css::SomeNamespace::SomeInterface>());
and
css::uno::Reference<css::SomeNamespace::SomeInterface> xSomeInterface(xAnotherInterface, css::uno::UNO_QUERY_THROW);
would become
auto xSomeInterface(xAnotherInterface.queryThrow<css::SomeNamespace::SomeInterface>());
Change-Id: Ic42da364562b702cd468cc708fbda70394c4f2a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149368
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
uno_any_destruct will get called by the other Any anyway, so no need to
do it ourselves.
And inline the helper now, since it is only used in the one spot.
Change-Id: If4227ce7e9d8ef83e3440ac1d9fe2579ed3583e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134597
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
There is just no good reason not to use a css::uno::Any constructor instead, so
simplify the code base. For URE backwards compatibility, keep it around as
deprecated for !LIBO_INTERNAL_ONLY.
Change-Id: I9409d8853cac270d47377a31ba35a1fc23fa9800
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133879
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...like was already present for css::uno::makeAny, in preparation of getting rid
of makeAny
Change-Id: Ic838a8297ec65dae75da6a1deb5933d562070753
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133679
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It missed some occurrences of 0 when only looking into uninstantiated template
code, as Clang doesn't model them with an ImplicitCastExpr, even if the target
is known to be a (dependent) pointer type.
Looking into all template instantiations of course carries the risk that a given
use of 0 is meant to be interpreted as a pointer in some and as an integer in
other instantiations. But the only case where that happened in the current code
base is RegistryValueList::getElement (include/registry/registry.hxx), where {}
is arguably a better choice anyway. (And which would presumably also hold for
any future such cases.)
Change-Id: I708bcfc8bedc0a49c9282d7814eb325afa29905c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128462
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Coverity had reported it as lacking, which
b0b2d7f040 "cid#1495784 Missing move assignment
operator" and c4aa4b55e2 "cid#1495784 Missing move
assignment operator" had worked around by instead modifying the calling code.
But even though a move constructor would be of little benefit, a move assignment
operator does have the slight performance benefit of avoiding some refcount
manipulation, so add it anyway.
Change-Id: Ibc9ca4557dd8beb6070b3451cb6103a8aadd10e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127188
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This makes all non-const operations on Sequence explicit, to avoid
repeated COW checks in loops. Generally it would be desirable to
replace uses of Sequence with general-purpose containers wherever
possible, and only use Sequence for UNO API calls.
This change uncovered a very serious pre-existing problem inherent
to the Sequences used e.g. in range-based loops in our code: taking
a non-const reference to elements of a sequence, and then modifying
them at some later stage, brings a danger to also modify copies of
the Sequence, that were created between the points of taking the
reference and modifying it. This caused the change to
oox/source/drawingml/customshapeproperties.cxx, where
CustomShapeProperties::pushToPropSet took begin()/end() non-const
iterators to aGeoPropSeq at the start of the loop, and then in the
loop modified its elements and copied the Sequence passing it to
XPropertySet::setPropertyValue. This was the same also prior to
2484de6728, and only happened to not
cause problems because of *accidental* use of non-const operator[]
on the copy of the Sequence inside SdrCustomShapeGeometryItem ctor,
which *inadvertently* triggered COW, detaching the two copies one
from another.
This only emphasizes that we should minimize use of Sequences in
the codebase. I anticipate other similar problems uncovered by this
change, that happened to not break existing unit tests.
Change-Id: Id691d994a06eb14297c487ebb84d8e062e29fd47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123725
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@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>
not necessary for the optimisation I was going for, and actually less
efficient than just using the copy constructor
Change-Id: I0f2019a0bf032283fb6c8d5d834603ea7a5ce3c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117762
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Also, I needed to add
castToXInterface()
to the upcasting Reference::Reference constructor,
to resolve ambiguity in casting to XInterface.
Change-Id: Ica60190bc842444c37de56407b586aa267f08372
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
current attempt isn't working, try a different approach to
silence these warnings
Change-Id: I0cc97df0897abc665dfbb683d7aa0df55f8affb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103387
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
argument of type "const sal_Int8 *" is incompatible with parameter of type
"void *"
Change-Id: I0f1dba700516043d54c4e46edae9753312b5ad2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103071
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
The main reason for the "home-grown" UpCast introduced with
904b3d1fce "Up-cast conversion constructor for
css::uno::Reference" in 2013 was probably that we could not yet rely on C++11
std::is_base_of back then. A (welcome) side effect was that the derived class
could be incomplete.
However, specializations of UpCast relying on whether or not T2 is incomplete
are obviously an ODR violation if the type is incomplete in some TUs and
complete (and derived from T1) in others. And even if UpCast had internal
linkage, it would still be brittle that its behavior depends on the completeness
of T2 at the point of the template's instantiation, and not necessarily at the
point of use.
That means we should better base that ctor on std::is_base_of (which we can do
now since 39a1edd6fe "Make css::uno::Reference
upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on
Clang and GCC if the completeness requirements are not met. This change fixes
all the cases where types need to be complete now, plus any resulting
loplugin:referencecasting warnings ("the source reference is already a subtype
of the destination reference").
Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It looks like an oversight that 904b3d1fce "Up-
cast conversion constructor for css::uno::Reference" added it also for external
code. Making it LIBO_INTERNAL_ONLY allows to remove workarounds for old MSVC,
and may allow to simplify the code further in the future. (Though using
std::is_base_of, as suggested in the comment, is not easily possible, as it
would cause errors like
> include/c++/v1/type_traits:1726:59: error: incomplete type 'com::sun::star::lang::XMultiServiceFactory' used in type trait expression
> : public integral_constant<bool, __is_base_of(_Bp, _Dp)> {};
> ^
> include/c++/v1/type_traits:1731:7: note: in instantiation of template class 'std::__1::is_base_of<com::sun::star::beans::XPropertySet, com::sun::star::lang::XMultiServiceFactory>' requested here
> = is_base_of<_Bp, _Dp>::value;
> ^
> include/com/sun/star/uno/Reference.h:277:18: note: in instantiation of variable template specialization 'std::__1::is_base_of_v<com::sun::star::beans::XPropertySet, com::sun::star::lang::XMultiServiceFactory>' requested here
> std::is_base_of_v<interface_type, derived_type>
> ^
> ucbhelper/source/provider/getcomponentcontext.cxx:34:9: note: while substituting deduced template arguments into function template 'Reference' [with derived_type = com::sun::star::lang::XMultiServiceFactory]
> css::uno::Reference< css::beans::XPropertySet >(
> ^
> include/ucbhelper/getcomponentcontext.hxx:29:28: note: forward declaration of 'com::sun::star::lang::XMultiServiceFactory'
> namespace lang { class XMultiServiceFactory; }
> ^
with incomplete types.)
Change-Id: I6da3395df904797cec83c1f6ab24b386527d4cea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92802
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...in non-dependent templated code that Clang trunk now apparently processes
more aggressively, presumably since <https://github.com/llvm/llvm-project/
commit/878a24ee244a24c39d1c57e9af2e88c621f7cce9> "Reapply 'Fix crash on switch
conditions of non-integer types in templates'"
Change-Id: Ia3e4bc6cfe7cea9f816e9282563a8b38e40f0cec
Reviewed-on: https://gerrit.libreoffice.org/84649
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html> "char8_t
backward compatibility remediation", as implemented now by <https://gcc.gnu.org/
git/?p=gcc.git;a=commit;h=0c5b35933e5b150df0ab487efb2f11ef5685f713> "libstdc++:
P1423R3 char8_t remediation (2/4)" for -std=c++2a, deletes operator << overloads
that would print an integer rather than a (presumably expected) character.
But in these cases printing an integer is as expected, so add explicit casts.
Change-Id: I7c2f1afaa2982b284aef8af183b71466c37142c2
Reviewed-on: https://gerrit.libreoffice.org/84339
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
When I did the fast string concatenation, I didn't add any support
for number(), which simply returned a O(U)String, and so it did
the extra allocation/deallocation, although that could be avoided.
In order to support this, number() now returns a special temporary
return type, similarly to O(U)StringConcat, which allows delaying
the concatenation the same way.
Also similarly, the change of the return type in some cases requires
explicit cast to the actual string type. Usage of OString::getStr()
is so extensive in the codebase that I actually added it to the helper
class, after that it's only relatively few cases.
Change-Id: Iba6e158010e1e458089698c426803052b6f46031
Reviewed-on: https://gerrit.libreoffice.org/78873
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
but we needed to make moveAnyInternals noexcept, which is fine because
uno_any_construct is already noexcept
Change-Id: Iddbe7666d8649cde4e638099a17484193055f549
Reviewed-on: https://gerrit.libreoffice.org/78283
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
idea from mike kaganski
look for places where we can mark move operators as noexcept, which
makes some STL operations more efficient
Change-Id: Id732b89d1fcadd5ceb0ea2b9d159fed06136330f
Reviewed-on: https://gerrit.libreoffice.org/78251
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Andrea Gelmini