...to ease the implementation in C++ code of constructor-based <implementation>s
that shall be single-instance (and which would have been implemented with e.g.
cppu::creaetOneInstanceFactory for non--constructor-based <implementation>s).
See e.g. 6e35794cad "terminate XDesktop properly
in unit tests" and 6362ebab29 "dbaccess: create
instances with uno constructors" for the clumsy approach used until now, where
the C++ constructor function uses a static instance that is cleared in
dispose(), adding fake <singleton> entries to <implementation>s where necessary
so that the ServiceManager will call those XComponent::dispose() functions when
it itself gets disposed.
For every <implementation>, the ServiceManager already holds an Implementation
data structure, so it can easily hold a singleInstance there and clear it when
the ServiceManager gets disposed. (One consequence is that single-instance
implementations are now created with their Instance.mutex locked, but that
should not cause problems in practice, given that the construction of a single-
instance implementation should not recursively request its own construction
anyway.)
The new single-instance="true" attribute is mostly useful in combination with
the constructor attribute (see above), but it can also be used for non--
constructor-based <implementation>s, at least in theory.
(The single-instance="true" attribute is orthogonal to <singleton> elements.
There are existing single-instance services---even if those should arguably have
been defined as singletons in the first place---that can benefit from
single-instance="true". And there are <implementation>s that support one or
more <singleton>s alongside one or more <service>s, where the latter are not
single-instance.)
This new single-instance="true" attribute in *.component files should not
interfere with the lo_get_constructor_map machinery in the DISABLE_DYNLOADING
branch of cppuhelper::detail::loadSharedLibComponentFactory
(cppuhelper/source/shlib.cxx) used by Android, iOS and some fuzzer code.
AFAIU, the lo_get_constructor_map machinery should only ever come into play
after the ServiceManager has decided whether or not to create a new instance
based on the single-instance attributes in the *.component files.
This commit only provides the new single-instance="true" attribute. Actual
changes of <implementation>s and their C++ constructor functions are delegated
to a series of follow-up commits. (So that they can easily be reverted
individually should the need arise.)
Change-Id: Iea6c0fc539d74477b7a536dc771b198df6b0510e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103734
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
to look for the
x.get() != null
pattern, which can be simplified to
x
I'll do the
x.get() == nullptr
pattern in a separate patch, to reduce the chances of a mistake
Change-Id: I45e0d178e75359857cdf50d712039cb526016555
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95354
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
"Find explicit casts from signed to unsigned integer in comparison against
unsigned integer, where the cast is presumably used to avoid warnings about
signed vs. unsigned comparisons, and could thus be replaced with
o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx)
o3tl::make_unsigned requires its argument to be non-negative, and there is a
chance that some original code like
static_cast<sal_uInt32>(n) >= c
used the explicit cast to actually force a (potentially negative) value of
sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the
cast to avoid a false "signed vs. unsigned comparison" warning in a case where
n is known to be non-negative. It appears that restricting this plugin to non-
equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=)
is a useful heuristic to avoid such false positives. The only remainging false
positive I found was 0288c8ffec "Rephrase cast
from sal_Int32 to sal_uInt32".
But which of course does not mean that there were no further false positivies
that I missed. So this commit may accidentally introduce some false hits of the
assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan
--enable-dbgutil) `make check && make screenshot`.
It is by design that o3tl::make_unsigned only accepts signed integer parameter
types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses
which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in
include/oox/helper/helper.hxx is used with both signed and unsigned types, so
needs a little oox::detail::make_unsigned helper function for now. (The
ultimate fix being to get rid of the macro in the first place.)
Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
found using 'git grep', I tried using clang-tidy, but it only
successfully found a tiny fraction of these
Change-Id: I61c7d85105ff7a911722750e759d6641d578da33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...and rename constructor members to constructorName/constructorFn for
disambiguation.
"Splitting ImplementationInfo out of Implementation has become necessary to
avoid circular references" in c16d0dd846
"fdo#49291 Postpone actual factory instantiation as long as possible", but was
no longer necessary since 997d211833 "Support for
singleton constructor functions" (which also removed the need to hold
ImplemenationInfo by shared_ptr, which has already been cleaned up with
fc11bce491 "ImplementationInfo can be inlined").
Change-Id: I51467aa7b1fce56d6549738efd1f34f91925dac5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86013
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Helps filter stupid stuff that makes no sense for online - eg.
reportbuilder or jdbc.
Change-Id: I40e06954c45fdefd21528202f4587ae83eb994c2
Reviewed-on: https://gerrit.libreoffice.org/69567
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I0eebd82b96d630da0597166cf87d398072607c13
Reviewed-on: https://gerrit.libreoffice.org/67473
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
KDE4 is out of maintenance upstream since Nov. 2014, and binaries
provided by TDF have switched to KDE5 as the official backend.
Change-Id: I165465b56d3ba3a18912b203c06ae8fc6111c0c9
Reviewed-on: https://gerrit.libreoffice.org/60014
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
That *is* what we want, I guess, so better I do it proactively before
I am told to do it. Sorry for the back and forth, but my main point in
touching this code was anyway the filtering out of the component (the
KDE4Backend thing) that causes a crash for me, at least, and which it
presumably is fairly pointless to preload anyway.
Also, filter out libraries that for some reason have an empty name.
Change-Id: I2cffd51e67c23977e0779e7f0d6faaf59d8819d9
As the 1aedb6c434 commit message said,
the point is that we want this output even with a LO built for
production where SAL_INFO() and SAL_WARN() are no-ops.
Change-Id: I5f788c3914286ca8df2c7e290150adae0be42820
Use just SAL_INFO(), with tag "cppuhelper.preload". No unconditional
writes to std::cerr. Also, log the loading attempt beforehand, so that
it is printed before any crash during the loading of a component.
Change-Id: Ifde8be8cb5d18dd88df21c45c906deb575d36960
...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
...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
