...than 25313923b0 "Fix CppunitTest_services for
constructor-based implementations..." (which this commit reverts again). My
claim that "the 'factory' would be the object itself" is nonsense, it would
rather be an ImplementationWrapper (but one that was freshly created for each
ServiceManager::createContentEnumeration).
Change-Id: I85c683cff6f9ba78d0f8567a53f8fcbc56fe55cf
...(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>
ae3a0c8da5 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>
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
Intended to be used from an application like the LibreOffice On-Line
server so that it can be called in a process that then will call
fork() several times, and much space consuming data will end up being
shared.
Change-Id: I65341c57d00308d246ec90deab8050b2c4bb3e61
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
It's not very efficient, because we generally end up copying it twice -
once into the parameter and again into the destination OUString.
So I create a clang plugin that finds such places and generates a
warning so that we can convert them to pass-by-reference.
Change-Id: I5341a6ea9e3190f4b4c05c42c85595e3dcd83361
It only tracks whether to dispose a singleton instance now, and (at least
conceptually) no longer remembers the single instance (apart from what is
necessary in order to call dispose on it), as the underlying implementation
already needs to keep track of that to support direct calls of constructor
functions.
Change-Id: I154bf05438e1db099c1c5ffb1c56377725c6bfc6
This is much better approach compared to the callback function, as it allows
passing arguments to the c++ constructor directly, while still allowing some
additional initialization after having acquired the instance.
Change-Id: I5a0f981915dd58f1522ee6054e53a3550b29d624
Many of the initalizations (in eg. framework) have to be done on an
acquire()'d object, so instead of doing the initialization directly, return
the initialization member function back to the createInstance() /
createInstanceWithContext() / ... and perform the initialization there.
As a sideeffect, I belive the calling initialize() from servicemanager is not
that much a hack any more - whoever converts the implementation to be
constructor-base has the choice to provide the callback, or still initialize
through XInitialization, where the callback is preferred by servicemanager
when it exists.
Change-Id: I8a87b75c54c1441ca0f184967d31ff4902fc4081
The service manager now keeps track of instances of singleton implementations
(i.e., implementations whose XML description lists at least one
<singleton ...>). These instances will be disposed either when the service
manager is disposed, or, for instances that have been instantiated into the
component context's /singleton/* map, when the component context is disposed.
This change allows to use constructor functions for such singleton
implementations, too.
Change-Id: I220c9ddc9824e4d7f7556daefb599e2ec36b0e6c
...to directly call constructor functions of ComponentContext-based C++
implementations of (non-single-instance) UNO services. The case where these
calls would need to be bridged across different environments (e.g., from gcc3
to gcc3:affine) is not yet implemented.
bootstrap.component and expwrap.component are adapted accordingly as a proof-of-
concept (which had previously been adapted to use the prefix="direct" feature,
which may become unnecessary again in the end, depending on how to handle
single-instance services/singletons). More to follow.
Change-Id: I18682d75bcd29d3d427e31331b4ce8161dbb846d
...for internal loader="com.sun.star.loader.SharedLibrary" components, instead
of exported component_getImplementationEnvironmen (or implicit
CPPU_CURRENT_LANGUAGE_BINDING_NAME). Adapted a few .component files as proof-
of-concept, more to follow.
Change-Id: I82332e0a48e6fc1da245990bb72265fe6e58447e
