...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...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>
Gabor Kelemen