...which caused e.g. UITest_writer_tests3 to occasionally hang with the
python.bin process thread 1 at
> File "sw/qa/uitest/writer_tests3/insertPageFooter.py", line 30, in delete_footer
[...]
i.e.,
> #4 ___pthread_cond_wait at /usr/src/debug/glibc-2.35-4.fc36.x86_64/nptl/pthread_cond_wait.c:618
> #5 0x00007ff9d6ad9c43 in cppu_threadpool::JobQueue::enter(void const*, bool) at cppu/source/threadpool/jobqueue.cxx:72
> #6 0x00007ff9d6ae8e79 in cppu_threadpool::ThreadPool::enter(rtl::ByteSequence const&, void const*) at cppu/source/threadpool/threadpool.cxx:303
> #7 0x00007ff9d6ae9278 in uno_threadpool_enter(uno_ThreadPool, void**) at cppu/source/threadpool/threadpool.cxx:407
> #8 0x00007ff9c7d016eb in binaryurp::Bridge::makeCall(rtl::OUString const&, com::sun::star::uno::TypeDescription const&, bool, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >&&, binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) at binaryurp/source/bridge.cxx:604
> #9 0x00007ff9c7d322fc in binaryurp::Proxy::do_dispatch_throw(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const at binaryurp/source/proxy.cxx:168
> #10 0x00007ff9c7d338cb in binaryurp::Proxy::do_dispatch(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const at binaryurp/source/proxy.cxx:101
> #11 0x00007ff9d63222e0 in cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, typelib_TypeDescription const*, typelib_TypeDescriptionReference*, sal_Int32, typelib_MethodParameter*, void**, void**, void**, sal_uInt64*) at bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:191
> #12 0x00007ff9d6322b59 in cpp_vtable_call(sal_Int32, sal_Int32, void**, void**, void**, sal_uInt64*) at bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:389
> #13 0x00007ff9d63336ca in privateSnippetExecutor at instdir/program/libgcc3_uno.so
> #14 0x00007ff9d6241f38 in (anonymous namespace)::ImplIntrospectionAccess::hasByName(rtl::OUString const&) at stoc/source/inspect/introspection.cxx:1114
> #15 0x00007ff9d6b856b2 in pyuno::PyUNO_getattr(PyObject*, char*) at pyuno/source/module/pyuno.cxx:1392
[...]
doing a remote call to soffice.bin with GIL locked, and thread 4 at
> #6 0x00007ff9e51efa28 in take_gil at workdir/UnpackedTarball/python3/Python/ceval_gil.h:207
> #7 0x00007ff9e51f00d3 in PyEval_AcquireThread at workdir/UnpackedTarball/python3/Python/ceval.c:316
> #8 0x00007ff9d6b9b1e8 in pyuno::Adapter::invoke(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, com::sun::star::uno::Sequence<short>&, com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) at pyuno/source/module/pyuno_adapter.cxx:181
> #9 0x00007ff9d632b3e4 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) at bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:77
> #10 0x00007ff9d632a4f1 in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, typelib_TypeDescriptionReference*, sal_Int32, typelib_MethodParameter*, void*, void**, uno_Any**) at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:233
> #11 0x00007ff9d632a9e6 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch(uno_Interface*, typelib_TypeDescription const*, void*, void**, uno_Any**) at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:413
> #12 0x00007ff9d621384a in stoc_invadp::(anonymous namespace)::AdapterImpl::invoke at stoc/source/invocation_adapterfactory/iafactory.cxx:457
> #13 stoc_invadp::adapter_dispatch(uno_Interface*, typelib_TypeDescription const*, void*, void**, uno_Any**) at stoc/source/invocation_adapterfactory/iafactory.cxx:605
> #14 0x00007ff9c7d1a7db in binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) const at include/typelib/typedescription.hxx:155
> #15 0x00007ff9c7d1d65f in binaryurp::IncomingRequest::execute() const at binaryurp/source/incomingrequest.cxx:78
> #16 0x00007ff9c7d33ad3 in binaryurp::(anonymous namespace)::request(void*) at ~/gcc/trunk/inst/include/c++/12.0.1/bits/unique_ptr.h:172
> #17 0x00007ff9d6ad9e1b in cppu_threadpool::JobQueue::enter(void const*, bool) at cppu/source/threadpool/jobqueue.cxx:100
> #18 0x00007ff9d6adbb80 in cppu_threadpool::ORequestThread::run() at cppu/source/threadpool/thread.cxx:164
[...]
processing an unrelated incoming call from soffice.bin and blocked trying to
lock the GIL. (The reason that thread 1 doesn't make progress is that the
soffice.bin process is also blocking with thread 6 at
> #8 osl::Guard<comphelper::SolarMutex>::Guard(comphelper::SolarMutex&) at include/osl/mutex.hxx:142
> #9 SolarMutexGuard::SolarMutexGuard() at include/vcl/svapp.hxx:1368
> #10 sw::(anonymous namespace)::XStyleFamily::hasByName(rtl::OUString const&) at sw/source/core/unocore/unostyle.cxx:923
> #11 0x00007f089d3d53e4 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) at bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:77
> #12 0x00007f089d3d44f1 in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, typelib_TypeDescriptionReference*, sal_Int32, typelib_MethodParameter*, void*, void**, uno_Any**) at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:233
> #13 0x00007f089d3d49e6 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch(uno_Interface*, typelib_TypeDescription const*, void*, void**, uno_Any**) at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:413
> #14 0x00007f089c1be7db in binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) const at include/typelib/typedescription.hxx:155
> #15 0x00007f089c1c165f in binaryurp::IncomingRequest::execute() const at binaryurp/source/incomingrequest.cxx:78
> #16 0x00007f089c1d7ad3 in binaryurp::(anonymous namespace)::request(void*) at ~/gcc/trunk/inst/include/c++/12.0.1/bits/unique_ptr.h:172
> #17 0x00007f08a18ade1b in cppu_threadpool::JobQueue::enter(void const*, bool) at cppu/source/threadpool/jobqueue.cxx:100
> #18 0x00007f08a18afb80 in cppu_threadpool::ORequestThread::run() at cppu/source/threadpool/thread.cxx:164
[...]
processing the incoming call from python.bin thread 1 and blocked trying to lock
the SolarMutex, while thread 1 at
> #4 ___pthread_cond_wait at /usr/src/debug/glibc-2.35-4.fc36.x86_64/nptl/pthread_cond_wait.c:618
> #5 0x00007f08a18adc43 in cppu_threadpool::JobQueue::enter(void const*, bool) at cppu/source/threadpool/jobqueue.cxx:72
> #6 0x00007f08a18bce79 in cppu_threadpool::ThreadPool::enter(rtl::ByteSequence const&, void const*) at cppu/source/threadpool/threadpool.cxx:303
> #7 0x00007f08a18bd278 in uno_threadpool_enter(uno_ThreadPool, void**) at cppu/source/threadpool/threadpool.cxx:407
> #8 0x00007f089c1a56eb in binaryurp::Bridge::makeCall(rtl::OUString const&, com::sun::star::uno::TypeDescription const&, bool, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >&&, binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) at binaryurp/source/bridge.cxx:604
> #9 0x00007f089c1d62fc in binaryurp::Proxy::do_dispatch_throw(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const at binaryurp/source/proxy.cxx:168
> #10 0x00007f089c1d78cb in binaryurp::Proxy::do_dispatch(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const at binaryurp/source/proxy.cxx:101
> #11 0x00007f089d3cc2e0 in cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, typelib_TypeDescription const*, typelib_TypeDescriptionReference*, sal_Int32, typelib_MethodParameter*, void**, void**, void**, sal_uInt64*) at bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:191
> #12 0x00007f089d3ccb59 in cpp_vtable_call(sal_Int32, sal_Int32, void**, void**, void**, sal_uInt64*) at bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:389
> #13 0x00007f089d3dd6ca in privateSnippetExecutor at instdir/program/libgcc3_uno.so
> #14 0x00007f08a6b5d170 in operator() at sfx2/source/notify/globalevents.cxx:491
> #15 comphelper::OInterfaceContainerHelper4<com::sun::star::document::XDocumentEventListener>::forEach<(anonymous namespace)::SfxGlobalEvents_Impl::implts_notifyListener(const com::sun::star::document::DocumentEvent&)::<lambda(const com::sun::star::uno::Reference<com::sun::star::document::XDocumentEventListener>&)> > at include/comphelper/interfacecontainer4.hxx:285
> #16 at sfx2/source/notify/globalevents.cxx:488
> #17 0x00007f08a6b04c8b in (anonymous namespace)::NotifySingleListenerIgnoreRE<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent>::operator() (listener=Python Exception <class 'gdb.error'>: Dwarf Error: Cannot find DIE at 0x0 referenced in module instdir/program/libmergedlo.so
> #18 comphelper::OInterfaceContainerHelper2::forEach<com::sun::star::document::XDocumentEventListener, at include/comphelper/interfacecontainer2.hxx:271
> #19 SfxBaseModel::postEvent_Impl(rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::frame::XController2> const&, com::sun::star::uno::Any const&) at sfx2/source/doc/sfxbasemodel.cxx:3253
> #20 0x00007f08a6b066fe in SfxBaseModel::Notify(SfxBroadcaster&, SfxHint const&) at sfx2/source/doc/sfxbasemodel.cxx:2902
> #21 0x00007f08a6f15def in SfxBroadcaster::Broadcast(SfxHint const&) at svl/source/notify/SfxBroadcaster.cxx:39
> #22 0x00007f087d640650 in SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) at sw/source/core/layout/layact.cxx:2389
> #23 0x00007f087dc0832b in SwViewShell::LayoutIdle() at sw/source/core/view/viewsh.cxx:821
> #24 0x00007f087d2ba194 in sw::DocumentTimerManager::DoIdleJobs(Timer*) at sw/source/core/inc/rootfrm.hxx:206
> #25 0x00007f08a89fbd26 in Scheduler::CallbackTaskScheduling() at vcl/source/app/scheduler.cxx:472
> #26 0x00007f08a8ca8780 in SalTimer::CallCallback() at vcl/inc/saltimer.hxx:54
> #27 SvpSalInstance::CheckTimeout(bool) at vcl/headless/svpinst.cxx:212
> #28 0x00007f08a8ca99bd in SvpSalInstance::ImplYield(bool, bool) at vcl/headless/svpinst.cxx:452
> #29 0x00007f08a8ca9db1 in SvpSalInstance::DoYield(bool, bool) at vcl/headless/svpinst.cxx:524
> #30 0x00007f08a8a27d4c in ImplYield(bool, bool) at vcl/source/app/svapp.cxx:474
> #31 0x00007f08a8a28445 in Application::Execute() at vcl/source/app/svapp.cxx:452
[...]
is doing the remote call to python.bin thread 4 with the SolarMutex erroneously
locked. But lets concentrate on just fixing the python.bin deadlock in this
commit.)
The PyThreadDetach antiguard just covering the xInvocation->getValue call in the
"or a property" case had been added with
e0a1cd4dc7 "fixed a deadlock", presumably without
taking into account that the xInvocation->hasMethod/hasProperty calls are
equally problematic.
Change-Id: I2483949df8213c3397a674be190224ee58c95c02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132428
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
- Change implementations of getSomething to use getSomethingImpl
Or where that's impossible, use getSomething_cast to unify this and
reduce number of places where we reinterpret_cast.
All static methods getting tunnel ids were renamed to getUnoTunnelId,
to comply with the convention used in <comphelper/servicehelper.hxx>.
TODO (in separate commits):
- Revise uses of getSomething to use getFromUnoTunnel
Change-Id: Ifde9e214b52e5df678de71fcc32d2199c82e85cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122100
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
- Replace all uses of OImplementationId in core with UnoIdInit
- Deprecate OImplementationId in <cppuhelper/typeprovider.hxx>
OImplementationId uses broken double checked locking; additionally,
it uses it at the first call to getImplementationId, not when the
object is constructed. This implementation can't be changed, cince
it's part of published API; it can't rely on C++11, which would be
required for use of thread-safe statics and move the initialization
to ctor.
The class has obsolete _bUseEthernetAddress member, that is unused
and ignored since 4e9fa7e339. No need
to implement it when replacing its uses to UnoIdInit.
The deprecation is the API CHANGE. No published API is introduced to
replace it; 3rd-party code should seek alternative solutions, or just
keep using the deprecated functionality.
TODO (in separate commits):
- Change implementations of getSomething to use getSomethingImpl
- Revise uses of getSomething to use getFromUnoTunnel
Change-Id: I8b6e684e5389bc0d5bb3b7f21f72a4c8f684107d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122077
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The header got some changes:
1. Move UnoTunnelIdInit and isUnoTunnelId into 'comphelper' namespace
2. Rename UnoTunnelIdInit to UnoIdInit, as a precondition to replace
of uses of OImplementationId with it, including in XTypeProvider
3. Introduce convenience functions 'getSomething_cast' to cast between
sal_Int64 and object pointers uniformly.
4. Rename getUnoTunnelImplementation to getFromUnoTunnel, both to make
it a bit shorter, and to reflect its function better. Templatize it
to take also css::uno::Any for convenience.
5. Introduce getSomethingImpl, inspired by sw::UnoTunnelImpl; allow it
handle cases both with and without fallback to parent.
6. Adjust UNO3_GETIMPLEMENTATION_* macros
TODO (in separate commits):
- Drop sw::UnoTunnelImpl and sw::UnoTunnelGetImplementation
- Replace all uses of OImplementationId in core with UnoIdInit
- Deprecate OImplementationId in <cppuhelper/typeprovider.hxx>
- Change implementations of getSomething to use getSomethingImpl
- Revise uses of getSomething to use getFromUnoTunnel
Change-Id: If4a3cb024130f1f552f988f0479589da1cd066e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122022
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>
This reverts commit f0356b6128.
Reason for revert: There is a OUStringConcat overload for OUStringBuffer which would have kicked in here, so this is unnecessary
Change-Id: I3bafb6c30bd3a2c1912daf227554889f1e09c78a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105354
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...where the goal is to check for a value in the range
[SAL_MIN_INT32 .. SAL_MAX_INT32], i.e., [-2^31 .. 2^31 - 1]: While C++17 (via C
LONG_MIN, LONG_MAX) only guarantees a range of [-(2^31 - 1) .. 2^31 - 1] for
long, C++20 now requires two's complement and a fitting range of at least
[-2^31 .. 2^31 - 1].
No need for 0d79d21688 "long->tools::Long in
pyuno..sd" here.
Change-Id: I6be60b50acfe5ed798cc8e9e1183c336c8d72059
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104712
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Until Python 3.7, PyTypeObject had a member tp_print following tp_dealloc, which
had then been repurposed as
> /* Methods to implement standard operations */
>
> destructor tp_dealloc;
> - printfunc tp_print;
> + Py_ssize_t tp_vectorcall_offset;
> getattrfunc tp_getattr;
> setattrfunc tp_setattr;
> PyAsyncMethods *tp_as_async; /* formerly known as tp_compare (Python 2)
in <https://github.com/python/cpython/commit/
aacc77fbd77640a8f03638216fa09372cc21673d> "bpo-36974: implement PEP 590
(GH-13185)" towards Python 3.8. Then only on the 3.8 branch (and prior to tag
v3.8.0), <https://github.com/python/cpython/commit/
d917cfe4051d45b2b755c726c096ecfcc4869ceb> "[3.8] bpo-37250: put back tp_print
for backwards compatibility (GH-14193)" added
> destructor tp_finalize;
> vectorcallfunc tp_vectorcall;
>
> + /* bpo-37250: kept for backwards compatibility in CPython 3.8 only */
> + Py_DEPRECATED(3.8) int (*tp_print)(PyObject *, FILE *, int);
> +
> #ifdef COUNT_ALLOCS
> /* these must be last and never explicitly initialized */
> Py_ssize_t tp_allocs;
at the end of PyTypeObject. This was apparently done so that third-party code
containing initialization code like
X.tp_print = 0;
would continue to compile (by just adding back a member with that name, even if
at a "random" new---and otherwise unused---location). However, for our way of
list-initializing PyTypeObject instances in pyuno that new member caused
"missing field 'tp_print' initializer" -Wmissing-field-initializers warnings, so
50ccb7e82b "python 3.8.2 compile: add tp_print to
PyTypeObject" added initializers for this new at-end member. But it did so in a
way that raises three concerns:
1 The new member was already added in Python 3.8.0 (prior to tag v3.8.0), not
only in 3.8.2.
2 The new member was only added to Python 3.8. It has not been added to
current master towards 3.9.
3 It is unclear why the comments mention "Py_ssize_t" as the type of that new
member, when actually it is of a function pointer type (see above). Probably
best to just drop that from the comments, to avoid confusion.
Change-Id: Ib44f43befd5f28d4c1ac1e9e14bd55bfb4473507
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94019
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...compared to d1786724b8 "prevent warnings in
pyuno with latest python". For one it is only the
/* bpo-37250: kept for backwards compatibility in CPython 3.8 only */
Py_DEPRECATED(3.8) int (*tp_print)(PyObject *, FILE *, int);
member (in /usr/include/python3.8/cpython/object.h) that causes a warning. And
for another it is only Clang that emits a warning when initializing a deprecated
member that way, <http://lists.llvm.org/pipermail/cfe-dev/2020-May/065392.html>
"[cfe-dev] Diagnosing initialization of deprecated data member?"
Change-Id: I36625118a6bb26f5468d436da4caa82911181202
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94016
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which has marked some members deprecated, but we can't stop initialising
them or we run the risk of ASAN complaining
Change-Id: I8f4ad0ae083fad9c040613ddde7c40f20d68c7d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93580
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
Python 2 support was retained for use with --enable-python=system
on RHEL7 and SLES. The time has arrived to remove it.
Some .py files that were imported from third parties are not changed to
enable easier replacement with updated versions if necessary.
solenv/gdb should continue to support Python 2.
bin/get-bugzilla-attachments-by-mimetype requires Python 2 to access
Launchpad.
Change-Id: I26414ae8e9f8402c90336af82020135685694217
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91697
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
I couldn't find this documented on the Internet though,
as the 3.9 and 3.8.2rc documentation didn't mention it
as an added item...
I'm using Ubuntu 20.04 alpha with python3 --version
Python 3.8.2rc1
This fixes pyuno/source/module/pyuno.cxx:1689:1: error:
missing initializer for member ‘_typeobject::tp_print’
[-Werror=missing-field-initializers]
Change-Id: Idec5720050572b34628267cd94557dabf7edbf3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89247
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The use-after-free is easier to trigger than expected; i don't see how
it's possible to check this without a race.
Change-Id: I4afb7066d1bf6b34f4f56aa0f51be0643ae40a66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86481
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
pyuno/source/module/pyuno_runtime.cxx:984:57: error: use of undeclared identifier 'PyThread_get_thread_ident'
It's only an assert, so simply do it only for >=3.7.
Change-Id: Ia3fffc7a9af30780adff9bc7dbabe1727c1f8f54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86410
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
* external/python3/python-3.3.3-aix.patch.1:
most of it doesn't apply and AIX port isn't maintained anyway so
remove it for now
* external/python3/ubsan.patch.0:
apparently one of the files was removed
* 0001-3.6-bpo-17239-Disable-external-entities-in-SAX-parse.patch.1:
fixed upstream
* python3-osx-avoid-new-10.13.patch.1:
replace with simply passing ac_cv_func_utimensat=no to configure
* external/python3/python-3.5.4-ssl.patch.1:
project files to build OpenSSL removed upstream
* There have been changes to how python locates OpenSSL; new variables
OPENSSL_INCLUDES etc; it turns out that you have to pass one directory
to --with-openssl, as the variables cannot be passed
* libuuid.so.1 is a new dependency of the _uuid module
* libffi.so.6 is a new dependency of the _ctypes module (the bundled
copy of libffi for non-Darwin platforms was removed)
* python-3.3.0-pythreadstate.patch.1:
the PyThreadState functions have been changed such that
CppunitTest_services asserts when there is a PyThreadAttach on top of
PyThreadDetach on top of PyThreadAttach, i.e., 2 PyThreadState per
thread (PyGILState_Check() fails). Instead of patching in additional
workarounds, change PyThreadAttach so that it re-uses an existing
PyThreadState if one exists for the thread.
Change-Id: I24c19d79b43a30709261fd9db66312b2e3872fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84765
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
...following up on 314f15bff0 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
buldi