It had been using cppu::OComponentHelper (which derives from XAggregation) ever
since b525a3115f "initial import", bug e.g.
ORegistryFactoryHelper deriving from it implements queryInterface in a way that
is incompatible with XAggregation (it should only have forwarded to
OFactoryComponentHelper::queryInterface, and rather implemented its logic in an
ORegistryFactoryHelper::queryAggregation override).
Also, without this commit but instead with a local
> diff --git a/cppuhelper/source/factory.cxx b/cppuhelper/source/factory.cxx
> index c8efcab0e604..9011264b3f3a 100644
> --- a/cppuhelper/source/factory.cxx
> +++ b/cppuhelper/source/factory.cxx
> @@ -241,6 +241,7 @@ class OFactoryComponentHelper
> , public OComponentHelper
> , public OSingleFactoryHelper
> {
> + void SAL_CALL setDelegator(css::uno::Reference<css::uno::XInterface> const &) final { assert(false); }
> public:
> OFactoryComponentHelper(
> const Reference<XMultiServiceFactory > & rServiceManager,
`make check` still succeeded for me on Linux, without hitting that injected
assert that should have fired if that XAggregation mechanism had been used after
all.
So switch from OComponentHelper to WeakComponentImplHelper here (which is the
simplest implementation helper to use, even if it still needs the non-standard
OFactoryComponentHelper::getTypes overriding the non-fitting
WeakComponentImplHelper default implementation).
Change-Id: I9fc2f4f2ef36bd016f9a943a8efd5e4ac5f3baaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145428
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...as it doesn't make sense that e.g. OFactoryComponentHelper::createInstance
checked for bOneInstance, called OSingleFactoryHelper::createInstance, which
called [OFactoryComponentHelper::]createInstanceWithContext, which checked for
bOneInstance again
Change-Id: I53f54079a2ac1af18a6e95f0cb9d7b75c1e46ceb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145418
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
4bfc00aca2 "#67468# factories support
XUnloadingPreference now" had added the check for XUnloadingPreference there,
but that's already covered by OFactoryComponentHelper::queryAggregation
delegating to OSingleFactoryHelper::queryInterface. (And as
OFactoryComponentHelper is inheriting XAggregation via OComponentHelper, the
only thing that OFactoryComponentHelper::queryInterface shall do is delegate to
OComponentHelper::queryInterface.)
Change-Id: Iebe507e88791d1e2390d042a8a9c152512ce212a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145420
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which were used by ildc, which is gone since
a8485d558f "[API CHANGE] Remove deprecated idlc
and regmerge from the SDK", and have always been ignored as legacy by its
unoidl-write replacement.
This change has been carried out (making use of GNU sed extensions) with
> for i in $(git ls-files \*.idl); do sed -i -z -E -e 's/\n\n((#[^\n]*\n)+\n)*(#[^\n]*\n)+\n?/\n\n/g' -e 's/\n(#[^\n]*\n)+/\n/g' "$i"; done && git checkout extensions/source/activex/so_activex.idl odk/examples/OLE/activex/so_activex.idl
which apparently happened to do the work. (The final two files are not UNOIDL
source files.)
Change-Id: Ic9369e05d46e8f7e8a304ab01740b171b92335cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135683
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
found by examining the call sites of OString::getToken
which means I needed to add a new o3tl::equalsAscii function
Change-Id: I7dc0ea1cf5ce8090a708d44f2cf7c938fa200c5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133826
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...where a signed and an unsigned value are compared, and the signed value has
just been proven to be non-negative here
Change-Id: I9665e6c2c4c5557f2d4cf1bb646f9fffc7bd7d30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133442
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
for
commit 27352b8163 (origin/master, origin/HEAD)
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Feb 21 16:00:52 2022 +0200
Add XWeak constructor and operator= to uno::WeakReference
I accidentally created a new gerrit change for this, and thus managed to
miss sorting out various review comments.
(*) Fix version number in gcc3.map
(*) Narrow the interface (i.e. assume non-null parameter) in
WeakReferenceHelper
(*) Remove cargo-cult catch and OSL_ASSERT in WeakReferenceHelper
(*) Remove accidental indentation
Change-Id: I8d1b22dd42216e9293959032d92df65405fb054c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130349
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Guess in all the fixing when upstreaming all the WASM changes,
that hunk got lost. This actually makes the WASM build run, not
just compile.
Change-Id: Ided621af284e62961eb47957d74b31871a30a2bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129105
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
... and use the same fake exception rethrowing code then the
mobile platforms.
Change-Id: Ic90de1cfd1e0092d6064d041a613d60d9f5f76b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128596
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...to 76e04aef4b "Rename LO-specific uno ini-file
(Linux: program/unorc) to 'louno'". (And yes, the original comment guessed
right: it is the URE uno ini-file that we look for here.)
Change-Id: I3006a5169ae066b984e415d17841f69db338b68b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128325
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
I assume this was originally added to work around some broken doc
generator, but we don't enforce comments for namespaces today, so this
is no longer needed.
Change-Id: Ia2311658516be84b26ae69e09362af560d793a7f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126963
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
That flag is only supported by clang-cl, not by MSVC, and
c7c9f3f57a "use clang-cl's -Zc:dllexportInlines-
for clang-cl builds" apparently naively assumed that it would work to build LO
with clang-cl and that flag without actually trying it out, and
1040228c35 "My clang-cl build does not work with
-Zc:dllexportInlines-" effectively disabled it completely.
The way to avoid unresolved external symbols during linking of URE libraries
(see the 1040228c35 commit message) is apparently
to also build libraries that the URE libraries depend on with the flag, hence
the change from gb_Library_set_is_ure_library to
gb_Library_set_is_ure_library_or_dependency. For now, I only marked those
additional libraries (unoil and xmlreader) that actually caused issues when
linking the URE libraries.
Change-Id: I3a85c73246250981cd86b7ee41f87b41f393a4b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126012
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
... 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>
... that happens while implementing the class declared as deprecated
with MSVC 2019.
cppuhelper/source/typeprovider.cxx(33): warning C4996: 'cppu::OImplementationId': Uses broken double checked locking
Change-Id: I469fe38bd276a554b1ef006d3da270b85f26554b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123422
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Use NSLog() and not just SAL_WARN(). There are so many irrelevant
SAL_WARN() warnings displayed that these ones that can be extremely
relevant are easily missed. I typically run the app in Xcode with
SAL_LOG=-WARN.
(Such warnings are typically caused by something missing from the
solenv/bin/native-code.py.)
Change-Id: I4ab16f4f652ac34319021c9427e2e9f911ee29e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122721
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122756
Tested-by: Jenkins
Stephan Bergmann