...rather than on the deprecated OComponentHelper.
Various classes like BaseContainerControl, FrameControl, and ProgressBar, all
deriving from BaseControl, had been found to implement their respective
queryInterface in a way that is incompatible with the XAggregation protocol
inherited via OComponentHelper. It looks like no code actually made use of the
XAggregation offered by this class hierarchy, so the easiest fix for those
queryInterface implementations appears to switch from OComponentHelper to
WeakComponentImplHelper.
Ideally, BaseControl would derive from WeakComponentImplHelper<XServiceInfo,
XPaintListener, XWindowListener, ...> covering all the UNO interface classes
from which it currently derives manually. But changing that manual
implementation across the BaseControl class Hierarchy looks tricky, so merely
introduce an "empty" WeakComponentImplHelper<> for now and keep all the manual
stuff, and leave proper clean up for later.
Change-Id: I1aa8b06f78700008f844415818f4a5801daa89b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145902
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
based on OInterfaceContainerHelper2 which is considerably
faster than the original OInterfaceContainerHelper
Change-Id: I9c8b6d0e5382018824bf7188a26343703abf2d51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120161
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
you cannot take a pointer to something inside a guard and then use that
data outside the guard.
So remove the broken locking here, and make sure the call sites hold the
lock.
Change-Id: I37cc363ff937243d7965844e8bcda0018085c656
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119370
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which can use the more efficient *StringConcat
Also fix a crash in stringview plugin which
started happening while I working on this.
Change-Id: I91a5b9b7707d1594d27d80b73930f5afac8ae608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to reduce the churn, we leave the existing constructor in place,
and add a clang plugin to detect when the value passed to the
existing constructor may contain transparency/alpha data.
i.e. we leave expressions like Color(0xffffff) alone, but
warn about any non-constant expression, and any expression
like Color(0xff000000)
Change-Id: Id2ce58e08882d9b7bd0b9f88eca97359dcdbcc8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109362
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Turns out we can save about 500Mb of preprocessor input if we use
rtl_math_approxEqual from rtl/math.h instead of its C++ wrapper
rtl::math::approxEqual from rtl/math.hxx
and manage the fallout accordingly.
Before:
bin/includebloat.awk | head
sum total bytes included (excluding system headers): 19017296671
After:
$ bin/includebloat.awk | head
sum total bytes included (excluding system headers): 18535432672
Change-Id: I1691171f3a309405a7099882ad9989d147f59118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92508
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
To mitigate the dangers of silently breaking ADL when moving enums into unnamed
namespaces (see the commit message of 206b5b2661
"New loplugin:external"), note all functions that are affected. (The plan is to
extend loplugin:external further to also warn about classes and class templates,
and the code to identify affected functions already takes that into account, so
some parts of that code are not actually relevant for enums.)
But it appears that none of the functions that are actually affected by the
changes in this commit relied on being found through ADL, so no adaptions were
necessary for them.
(clang::DeclContext::collectAllContexts is non-const, which recursively means
that External's Visit... functions must take non-const Decl*. Which required
compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support
such Visit... functions with non-const Decl* parameters.)
Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd
Reviewed-on: https://gerrit.libreoffice.org/83001
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: Id088a2c8a91c2fe7c8ff9e05d910d5b5e9383b7c
Reviewed-on: https://gerrit.libreoffice.org/72095
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Also use scope where possible. This allows to limit guard scope at
language level; visualises the scope clearly; and helps avoiding
errors like fixed in commit 61e4437c85.
Change-Id: Ifeca96e2df8e8a0897770d9546b2536806275f41
Reviewed-on: https://gerrit.libreoffice.org/70376
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
look for OUString being appended to in a loop, better to use
OUStringBuffer to accumulate the results.
Change-Id: Ia36e06e2781a7c546ce9cbad62727aa4c5f10c4b
Reviewed-on: https://gerrit.libreoffice.org/58092
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
There is exactly one implementation of css.frame.FrameControl (which demands a
property named "ComponentUrl" not "ComponentURL"), and exactly one place where
that property is used. So switch those two places to use the spelling of the
property name as documented in the UNOIDL service. (Even though that can be
considered an incompatible change, in the unlikely case that 3rd party code
expects to be able to access the given implementation's property with the mis-
spelled name.)
Change-Id: I4fa3f21851b61079c09deea1a24aac22bc96f36f
Reviewed-on: https://gerrit.libreoffice.org/51766
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
codemaestro