...and remove some unncessary using directives/declarations, in preparation of
removing now-unnecessary #includes from cppumaker-generated files, post
e57ca02849c3d87142ff5ff9099a212e72b8139c "Remove dynamic exception
specifications".
Change-Id: Iaf1f268871e2ee1d1c76cf90f03557527ebc9067
...(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>
sal_Bool and sal_uInt8 are typedefs for the same underlying type, so any use of
ORowSetValue with sal_Bool instead of bool, apparently intending to treat the
value as a boolean, actually treated it as a TINYINT. (See e.g. recent
7b0c57b2faec875c790051d233d1e9abaed2a3bc "some compilers don't like implicit
bool-to-ORowSetValue conversion".)
Now that there's no way to create a sal_uInt8 ORowSetValue, getUInt8 and the
m_uInt8 union member can probably go away, too.
Change-Id: Ia27554f76e7e9edce6410284b578064573e54fd3
Reviewed-on: https://gerrit.libreoffice.org/31909
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
also edited two examples in canvas comments
Change-Id: Iac82b462168f869f995c33bb2c639f3dbe09cbd5
Reviewed-on: https://gerrit.libreoffice.org/31715
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
...which is only ever called from onexcept XInterface::release overrides:
connectivity::release itself appears to be only called from
connectivity::OSubComponent::relase_ChildImpl [sic], which in turn is only
called from various XInterface::release overrides across connectivity.
Change-Id: I94b682ec531acecd0ef9f8c100f67a71c361941e
convert usage of deprecated class, and remove the old class
Change-Id: I19fb9271090d19e5531622b58492e1a848d306e2
Reviewed-on: https://gerrit.libreoffice.org/26843
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
This bizarre thing essentially does the same as
WeakComponentImplHelperBase::release(), except that
1) it forgets to call disposeWeakConnectionPoint()
2) it doesn't catch exceptions from dispose()
3) it restores the m_xParent member after the dispose() call
4) it's racy because the "else" branch may be executed at a time
when another thread has already concurrently deleted the object
This is rather mysterious and there is no obvious reason why a manual
dispose() call should clear m_xParent (as the users tend to do, by calling
dispose_ChildImpl() from their disposing()), but a dispose() called from
release() should restore m_xParent again.
Let's try to stop doing this madness and see if anything breaks.
Change-Id: I88a60fe1a7eeb625442faf436c9a3deb3c59941c
Reviewed-on: https://gerrit.libreoffice.org/26554
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
and fix the operator< implementations in some of the other
plugins too.
Change-Id: Ie5631e0cdc8d2a994ad2af2533cdb558a6cfc035
Reviewed-on: https://gerrit.libreoffice.org/25057
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
replace the old declare and don't implement pattern
with C++11 delete keyword
no need to hide this design choice behind access restrictions
Change-Id: I7e8430a07189aa48514a4613c3a8c2950b230f49
Reviewed-on: https://gerrit.libreoffice.org/24495
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Sequence.h(xx), Any.h(xx) and Type.h(xx)
and remove unused using-declarations from these files.
Add a few missing includes provided by them.
Change-Id: I6b91b6d1fdf9d0496dd546c0aab9bdcc6831a5d4
Reviewed-on: https://gerrit.libreoffice.org/23805
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
I either replaced OSL_DEBUG_LEVEL > 1 with OSL_DEBUG_LEVEL > 0
statements or i used SAL_INFO(..)s
Change-Id: Iefb6b83e86e1767e55600b6e1989ee91207fb220
Reviewed-on: https://gerrit.libreoffice.org/23000
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
