... 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>
This may be important with static empty sequence cppu::g_emptySeq, that is
common for sequences of different types.
The changes in sd/qa/unit/data/xml/*.xml fix places where anys with empty
Sequence<OUString> used to wrongly take 'if(aAny >>= aPropSeq)' branch in
dumpPropertyValueAsElement (drawinglayer/source/dumper/XShapeDumper.cxx).
Change-Id: I5b0544ca94b30437c01dd46f376408f91510bcb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124167
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...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>
...compared to a full-blown O[U]String, for temporary objects holding an
O[U]StringConcat result that can then be used as a std::[u16]string_view.
It's instructive to see how some invocations of operator ==, operator !=, and
O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit
materialization of an O[U]String temporary, and how that expensive operation has
now been made explicit with the explicit O[U]StringConcatenation ctor.
(The additional operator == and operator != overloads are necessary because the
overloads taking two std::[u16]string_view parameters wouldn't even be found
here with ADL. And the OUString-related ones would cause ambiguities in at
least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with
RTL_STRING_UNITTEST, so have simply been disabled for that special test-code
case.)
Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
no need to delay-init something we always need, and laying
out a std::unordered_map is something we can normally do at
link time anyway.
Change-Id: Ide791d20394580bca615aa3ad564c154037e0816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119137
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
In commit b33fbd55d6, many getMutex() have been replaced by an equivalent
maMutex.
Only in place, the use of a mutex have been simply removed.
Restore it as done in all the other places
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Change-Id: Id85e74e166ec57dd37f8913f8ecf19e2b6465f8f
---
This patch is completely speculative. The removal of this mutex was maybe
done on purpose.
This only looks spurious to me.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117402
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 0752de6850, as it causes
initialization-order-fiasco, e.g. when building Gallery_backgrounds:
> ==913067==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x7fee04a01ba0 at pc 0x7fee0467257e bp 0x7ffd678aaa30 sp 0x7ffd678aaa28
> READ of size 8 at 0x7fee04a01ba0 thread T0
> #0 in osl::Mutex::acquire() at include/osl/mutex.hxx:57:37 (instdir/program/libuno_cppu.so.3 +0x32957d)
> #1 in osl::Guard<osl::Mutex>::Guard(osl::Mutex&) at include/osl/mutex.hxx:138:17 (instdir/program/libuno_cppu.so.3 +0x316a4e)
> #2 in typelib_typedescriptionreference_new at cppu/source/typelib/typelib.cxx:2130:16 (instdir/program/libuno_cppu.so.3 +0x3e2d9a)
> #3 in typelib_static_type_getByTypeClass at cppu/source/typelib/static_types.cxx:266:17 (instdir/program/libuno_cppu.so.3 +0x3c04af)
> #4 in cppu::detail::getTypeFromTypeClass(_typelib_TypeClass) at include/cppu/unotype.hxx:110:9 (instdir/program/libxolo.so +0x2e87e61)
> #5 in cppu::detail::cppu_detail_getUnoType(signed char const*) at include/cppu/unotype.hxx:136:12 (instdir/program/libxolo.so +0x2e902dd)
> #6 in cppu::UnoType<signed char>::get() at include/cppu/unotype.hxx:296:16 (instdir/program/libxolo.so +0x2e90278)
> #7 in com::sun::star::uno::Type const& cppu::getTypeFavourUnsigned<signed char>(signed char const*) at include/cppu/unotype.hxx:321:12 (instdir/program/libxolo.so +0x2e90218)
> #8 in com::sun::star::uno::Type const& cppu::getTypeFavourUnsigned<signed char>(com::sun::star::uno::Sequence<signed char> const*) at include/com/sun/star/uno/Sequence.hxx:292:14 (instdir/program/libxolo.so +0x2e9001a)
> #9 in com::sun::star::uno::Sequence<signed char>::Sequence() at include/com/sun/star/uno/Sequence.hxx:59:26 (instdir/program/libxolo.so +0x2e8ff58)
> #10 in __cxx_global_var_init at xmloff/source/core/fasttokenhandler.cxx:35:48 (instdir/program/libxolo.so +0x3455d3f)
> #11 in _GLOBAL__sub_I_fasttokenhandler.cxx at xmloff/source/core/fasttokenhandler.cxx (instdir/program/libxolo.so +0x3455da4)
> #12 in call_init.part.0 at <null> (/lib64/ld-linux-x86-64.so.2 +0x108dd)
> #13 in _dl_init at <null> (/lib64/ld-linux-x86-64.so.2 +0x109c7)
> #14 at <null> (/lib64/ld-linux-x86-64.so.2 +0x10c9)
>
> 0x7fee04a01ba0 is located 0 bytes inside of global variable '(anonymous namespace)::s_Mutex' defined in 'cppu/source/typelib/typelib.cxx:286:12' (0x7fee04a01ba0) of size 8
> registered at:
> #0 in __asan_register_globals at ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_globals.cpp:360:3 (instdir/program/gengal.bin +0x28698d)
> #1 in asan.module_ctor at <null> (instdir/program/libuno_cppu.so.3 +0x42649b)
Change-Id: Iab673f048bfb76165de2c47c2db63e339069fd17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110228
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
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>
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>
bDesctructorCalled doesn't exist in the code anymore.
I guess we can delete the comment.
Change-Id: I551efe2298422e5139f1dd07a6b3bf4728763026
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100774
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
While tracking down the issue discussed in the commit message of
78dc7d982b "Remove a potentially already enqueued
response when a bridge is disposed", it occurred to me that there should be a
race in those
uno_threadpool_putJob(
bridge_->getThreadPool(), ...);
calls in binaryurp/source/reader.cxx, when the bridge gets disposed (through
some other thread) between the time the bridge_->getThreadPool() call checks for
the bridge being disposed (in which case it would throw a DisposedException) and
the actual uno_threadpool_putJob call.
I tried to catch that with a previous incarnation of this change
(<https://gerrit.libreoffice.org/c/core/+/96120/1> "Jenkins Slides Through the
Tiny Window"), but couldn't---presumably because this race would be very rare
after all, and the issue I was chasing turned out to be caused by something
different anyway. Nevertheless, I wanted to address this potential race now.
We can only reliably check for disposed'ness after having locked ThreadPool's
m_mutex in uno_threadpool_putJob -> ThreadPool::addJob, but at which time we can
no longer indicate this condition to the caller---uno_threapool_putJob is part
of the stable URE interface, has a void return type, and should not throw any
exceptions as it is a C function. However, if the bridge gets disposed, any
threads that would wait for this job (in cppu_threadpool::JobQueue::enter,
either from cppu_threadpool::ORequestThread::run waiting to process new incoming
calls, or from a bridge's call to uno_threadpool_enter waiting for a respose to
an outgoing call) should already learn about the bridge being disposed by
falling out of cppu_threadpool::JobQueue::enter with a null return value. So it
should be OK if uno_threadpool_putJob silently discards the job in that case.
Change-Id: I36fe996436f55a93d84d66cc0b164e2e45a37e81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96120
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This avoids the need for the tricky osl::Condition::reset calls. For example,
the first one (in the "disposed !" case) had been added with
2a3ed89284 "sb132: #i112448# proper clean up in
JobQueue::enter (patch by olistraub)" as
> if( 0 == m_lstCallstack.front() )
> {
> // disposed !
> + if( m_lstJob.empty() )
> + {
> + osl_resetCondition( m_cndWait );
> + }
> break;
> }
>
and then change to
> if( 0 == m_lstCallstack.front() )
> {
> // disposed !
> - if( m_lstJob.empty() )
> + if( m_lstJob.empty()
> + && (m_lstCallstack.empty()
> + || m_lstCallstack.front() != 0) )
> {
> osl_resetCondition( m_cndWait );
> }
with cba3ac1eab "Avoid deadlocks when disposing
recursive JobQueue::enter", which prevented the reset from ever hapening
(because m_lstCallstack.front() cannot both be zero and non-zero here at the
same time). The std::condition_variable semantics nicely avoid any reasoning
whether or not a reset would be necessary here.
Change-Id: Ic9b57b836bb6679829f4aa3b68679256726acf60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96406
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Noel Grandin