instead of fighting the fact that Sequence is intended to be immutable
getSequence() will become a little slower, but since getSequence()
is called 5k times during 'make check', while add/remove are called
3M times, I think it's safe to say mutation is dominant.
Change-Id: I23d127c93c589050d6c06c0da47871e1ebe7b52d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86929
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
idea from mike kaganski
look for places where we can mark move operators as noexcept, which
makes some STL operations more efficient
Change-Id: Id732b89d1fcadd5ceb0ea2b9d159fed06136330f
Reviewed-on: https://gerrit.libreoffice.org/78251
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
include/osl/thread.h:198: warning: argument 'name' from the argument list of osl_setThreadName has muliple @param documentation sections
include/cppuhelper/propshlp.hxx:329: warning: argument 'bIgnoreRuntimeExceptionsWhileFiring' from the argument list of cppu::IEventNotificationHook::fireEvents has muliple @param documentation sections
Change-Id: Ic1a2a7239596ec62c0d60c14480ea4a115eaaaa1
Reviewed-on: https://gerrit.libreoffice.org/68944
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
(added recently with d559c28e9e "expand out
IMPL_XTYPEPROVIDER_START macro"), for extra compatibility safety. (At least
MSVC exports non-inline versions of such CPPUHELPER_DLLPUBLIC inline functions
from the cppuhelper DLL.) The original getTypes (added back now with
<https://gerrit.libreoffice.org/#/c/68549/> "revert ABI change from 'expand out
IMPL_XTYPEPROVIDER_START macro'") had been a non-const member function ever
since at least b525a3115f "initial import",
presumably by accident. (Whether or not to return a reference is an orthogonal
issue. With the newly added overload being LIBO_INTERNAL_ONLY, it is presumably
fine to have it return a reference for now and see whether that causes any
issues with lifetimes of temporary OTypeCollection instances.)
Change-Id: If6abcf53b46b972204598774fed7cdd34d78440b
Reviewed-on: https://gerrit.libreoffice.org/68637
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ib420e9216b8313f5ed7634ec375e39ceb741fd45
Reviewed-on: https://gerrit.libreoffice.org/59297
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
...by explicitly defaulting the copy/move functions (and, where needed in turn,
also a default ctor) for classes that have a user-declared dtor that does
nothing other than an implicitly-defined one would do, but needs to be user-
declared because it is virtual and potentially serves as a key function to
emit the vtable, or is non-public, etc. (For LIBO_INTERNAL_ONLY.)
Change-Id: I9da48559b083bdec9b1b4014634f6f3bfb1c3de3
Reviewed-on: https://gerrit.libreoffice.org/58107
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...by removing explicitly user-provided functions that do the same as their
implicitly-defined counterparts, but may prevent implicitly declared copy
functions from being defined as non-deleted in the future
Change-Id: I2b7b6b8baa872addfb2adb0d551d78de1e31c896
Reviewed-on: https://gerrit.libreoffice.org/58106
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: I3966d302241a52014aaad41f72924a2095ea6621
Change these back to consistently use the "..." form to include other UNO API
include files, for the benefit of external users of this API.
Change-Id: I9c9188e895eb3495e20a71ad44abfa2f6061fa94
On Windows, UTF-8 is never current locale encoding; so using 8-bit
strings will always fail for paths containing characters outside
of current codepage.
Also fix leaks caused by failing to release its result: previously
it could return either result of getenv (that shouldn't get freed),
or an allocated string, but never got freed; now the result is
always allocated and properly freed.
Change-Id: I8b255dea20040eec0572de2b34280749fe8f071c
Reviewed-on: https://gerrit.libreoffice.org/42743
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
to markup dtors that coverity warns might throw exceptions
which won't throw in practice, or where std::terminate is
an acceptable response if they do
Change-Id: I32b94814e8245372e1d1dc36be0d81e3564042f4
Reviewed-on: https://gerrit.libreoffice.org/38318
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
...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>
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
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>
...it never did anything different than the generic template overload.
Strictly speaking, removing that inline function overload could be considered an
API change, but it shouldn't cause any issues in practice even when recompiling
all code against the new include files.
Change-Id: Icb0942f56ee0888f09d3478f34d568d44651c838
This reverts commit 0b04e8f80e, shuffling the code
around started to cause some builds to complain with -Werror=maybe-uninitialized
in places where they did not before. Needs a better fix.
The issue of 362d4f0cd4 "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
Julien Nabet