...from function definitions occurring within class definitions. Done with
a rewriting Clang plugin (to be pushed later).
Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8
Reviewed-on: https://gerrit.libreoffice.org/34874
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
ae3a0c8da50b36db395984637f5ad74d3b4887bc unfortunately forgot to
implement mapping between UNO environments for constructor functions
in the UNO service manager, and due to the many componennt conversions
to constructor functions since then, the log UNO purpose environment
has become mostly useless.
Save the environment, create a closure today!
https://wiki.openoffice.org/wiki/Uno/Spec/Log_Environment
Change-Id: Idc03b5ed9529da8e81cd91efe50cbeceffa2b247
Reviewed-on: https://gerrit.libreoffice.org/33060
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
* GCC documents -fvisibility at least as far back as the GCC 4.0 online
documentation at
<https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Code-Gen-Options.html>.
* For external code, odk/settings/settings.mk unconditionally set
HAVE_GCC_VISIBILITY_FEATURE for all platforms other than Windows.
Make this a fatal configure error for now. The check should be removed
completely after LO 5.3 branch-off.
Change-Id: I1de415b6ed1591e0a7b6640ece861b6f0ef74112
Reviewed-on: https://gerrit.libreoffice.org/29073
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
OWeakObject::m_pWeakConnectionPoint is returned from
OWeakObject::queryAdapter(), and stored in
OWeakRefListener::m_xWeakConnectionPoint.
This is cleared in OWeakRefListener::dispose(), called from
OWeakConnectionPoint::dispose(), called from
OWeakObject::disposeWeakConnectionPoint(), but it can happen that
another thread is in WeakReferenceHelper::get() and has copied
m_xWeakConnectionPoint onto the stack before the OWeakObject is
released and deleted, then calls OWeakConnectionPoint::queryAdapted()
after it is released, accessing the dead m_pObject.
Change-Id: I7782e6fb7e07f5a48cf7064115217376714ba8e8
... but its documentation claims that it is, which is partially
misleading, so fix both the documentation and the data race in
WeakReferenceHelper::clear().
This actually crashed in clear() in the multi-threaded ZipPackage code
on exporting the bugdoc from tdf#94212, presumably because clear()
races against OWeakRefListener::dispose().
Change-Id: I85665c11b8157e90d15e8263758e24e66efeb86c
After my commit 1e063e8b "optimise references list handling in
OWeakConnectionPoint"
Reduce scope of locking, and copy a the performance trick from
OInterfaceContainerHelper.
Change-Id: Idc218e9d4edf45f8c37c7e517d1a26821800448b
Reviewed-on: https://gerrit.libreoffice.org/25406
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
...which (in LIBO_INTERNAL_ONLY) for Clang expands to [[clang::fallthrough]] in
preparation of enabling -Wimplicit-fallthrough. (This is only relevant for
C++11, as neither C nor old C++ has a way to annotate intended fallthroughs.)
Could use BOOST_FALLTHROUGH instead of introducing our own SAL_FALLTHROUGH, but
that would require adding back in dependencies on boost_headers to many
libraries where we carefully removed any remaining Boost dependencies only
recently. (At least make SAL_FALLTHROUGH strictly LIBO_INTERNAL_ONLY, so its
future evolution will not have any impact on the stable URE interface.) C++17
will have a proper [[fallthroug]], eventually removing the need for a macro
altogether.
Change-Id: I342a7610a107db7d7a344ea9cbddfd9714d7e9ca
Searched source for using declarations.
Checked if those symbols reappear in the source file,
even in comments or dead code but not in #include statements.
If they don't reappear, remove the declaration.
Remove includes whose symbol got removed.
Change-Id: Ibb77163f63c1120070e9518e3dc0a78c6c59fab0
Reviewed-on: https://gerrit.libreoffice.org/24148
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
remove <boost/noncopyable.hpp> in pch and
remove boost from makefile if it was the only boost entry.
Change-Id: Icb945ae59c137571f4f63807601738eea5c3e831
Reviewed-on: https://gerrit.libreoffice.org/24061
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
