...which is there for MSVC compatibility, but can cause getBody() to return null
even when doesThisDeclarationHaveABody() is true.
And in staticmethods.cxx we need to check doesThisDeclarationHaveABody() instead
of hasBody(): For some class template member functions that are only defined
outside their class definition, as is the case for
OSequenceIterator::hasMoreElements in include/comphelper/sequence.hxx, hasBody()
may be true for the original member function declaration inside the class (as
there is some later definition that does have a body), but
isLateTemplateParsed() is not (it is only true for the later definition). So
just skip any such declarations that are not definitions (which is sane anyway,
as otherwise such functions could pointlessly be inspected multiple times).
Change-Id: I724f652a8f060a931f8b5fc3e4feb5f307a922bf
Reviewed-on: https://gerrit.libreoffice.org/42914
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
on classes which are fully defined in a header file
Rename the dllprivate plugin to dllmacro and add the functionality
there.
Change-Id: I4581d551c46a8f61213d95973f323359d08278d8
which makes absolutely no difference to the results, but anyhow, would
be a shame to waste the work
Change-Id: I4576528f30986a5ce522c76fdf21873f0ce23f0a
also make the plugin ignore the case where we have var decl's in the
clause we want to flatten, which could lead to problematic extension of
variable lifetime
Change-Id: I3061f7104e8c6a460bf74f5eac325a516ec50c59
Reviewed-on: https://gerrit.libreoffice.org/42889
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...as happens on Windows when looking at
maControlToPropertyMap.clear();
in PrintDialog::dispose (vcl/source/window/printdlg.cxx), where std::map's clear
happens to be declared at some base class std::_Tree.
Change-Id: I41810514bca59af8b4f2812d9412ce6a8d43576c
<noelgrandin> sberg, new plugin flatten just went active
<sberg> noelgrandin, with a measure to avoid extending lifetime of (problematic) local vars?
<noelgrandin> sberg, no
<sberg> noelgrandin, how can you make it active then?
<noelgrandin> sberg, ok, will disable
Change-Id: I595d1a50ff34417faf73b777714f9dc92e2a43d2
Reduce potential confusion with the global tools namespace. Will
hopefully make it possible to remove the annoying initial :: when
referring to the global tools namespace. Unless we have even more
tools subnamespaces somewhere.
Thorsten said it was OK.
Change-Id: Id088dfe8f4244cb79df9aa988995b31a1758c996
Reviewed-on: https://gerrit.libreoffice.org/42644
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
it is not legal to eliminate a catch/re-throw where the re-throw
expliciting mentions the exception variable and the exception variable
is a non-final class
Change-Id: I7fd88b0d004d2efa66aef2c0876e07f203da3c28
Reviewed-on: https://gerrit.libreoffice.org/42782
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
and implement a check in the plugin to prevent us modifying the
same patch of source code twice. This logic should probably be moved
into plugin.cxx at some point.
Change-Id: I7ebff6424cc8733bb2c8f7dba75eaaec68649290
Reviewed-on: https://gerrit.libreoffice.org/42660
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
That was a dead end anyway, trying to partly reimplement
SvFilterOptionsDialog ExportDialog, instead of implementing the
necessary bits to use that one which has everything.
Change-Id: Icde7422f2c2d7e26c07dfe921a4abda41e222b09
Reviewed-on: https://gerrit.libreoffice.org/42503
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
This reverts commit cd2725de90517cd63a17ccbf2c59c1e07eca5744.
Norbert's list of CI performance issues includes
"2/ clang plugin build should not be serialized (forced -j1)"
Change-Id: Ib77f951a31adc20f6a9f88e8b51632bd81273327
Reviewed-on: https://gerrit.libreoffice.org/42595
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
look for places where we can flatten the control flow in a method by
exiting early with a throw, ie. instead of
if (cond)
stuff();
else
throw ex;
we change it to:
if (!cond)
throw ex;
stuff();
Change-Id: I8b6bdf883b325807c7e3a3ef698e4f4606e7d38b
(*) IsPassedByNonConst was completely wrong, not even sure why it worked
before.
(*) treat a field passed to operator>>= as being written to, but not
read
Change-Id: Id3a5f2f35222986fe5edba3f5a58215a1815d401
...when t1 is ElaboratedType sugar (which isn't only used when the type is
written with an elaborated type keyword, but also when it is written with a
qualified name).
(I originally wrote testArithmeticTypedefs to track down a different issue,
which turned out to be a non-issue, with this fix as fall-out. So that test
doesn't quite match the theme of this commit, but is a worthwhile addition
nonetheless.)
Change-Id: Ic447da4399853d7d045e3e2e7ade8ddf52d89749
to find c-style casts where the expression is a templated method
Change-Id: Ifbd1e2cdc72d906fc95a7ec0f9408c3f6d2a836b
Reviewed-on: https://gerrit.libreoffice.org/42275
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...motivated by <https://gerrit.libreoffice.org/#/c/41565/2> adding dead code
at the end of a switch statement, after the last case's "break".
-Wunreachable-code appears to work well on Clang, while it appears to have no
effect on GCC.
Most of the affected places are apparently temporary/TODO/FIXME cases of
disabling code via "if (false)", which can be written with an extra set of
parentheses as "if ((false))" to silence -Wunreachable-code on Clang (which thus
needed loplugin:unnecessaryparen to be adapted accordingly). In some cases,
the controlling expression was more complex than just "false" and needed to be
rewritten by taking it out of the if statement to silence Clang.
One noteworthy case where the nature of the disabled code wasn't immediately
apparent:
Sep 12 16:59:58 <sberg> quikee, is that "if (false)" in
ScExponentialSmoothingDialog::ApplyOutput
(sc/source/ui/StatisticsDialogs/ExponentialSmoothingDialog.cxx) some work-in-
progress or dead code?
Sep 12 17:02:03 <quikee> sberg: WIP, but you can remove it
Sep 12 17:04:47 <sberg> quikee, I'll wrap the false in an extra set of
parentheses for now, to silence -Wunreachable-code (I wouldn't want to
remove it, as I have no idea whether I should then also remove the "Initial
value" comment preceding it)
Sep 12 17:07:29 <quikee> sberg: both are different ways to calculate the
"intital value"... so no
Another case where the nature of the dead code, following while (true) loops
without breaks, is unclear is sd/source/ui/remotecontrol/BluetoothServer.cxx,
where I added TODO markers to the workarounds that silence the warnings for now.
basic/source/sbx/sbxvalue.cxx had a variable of type double, of automatic
storage duration, and without an initalizer at the top of a switch statement.
Clang warning about it is arguably a false positive.
Apart from that, this didn't find any cases of genuinely dead code in the
existing code base.
Change-Id: Ib00b822c8efec94278c048783d5997b8ba86a94c
Reviewed-on: https://gerrit.libreoffice.org/42217
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...to find uses of dynamic_cast where the static (base) type has hidden
visibility while the dynamic (derived) one has default visibility, and which may
thus fail at least on macOS like happened in
d5ed3cd6dbd22bb18542778f1c48f4d5b3ae0f95 "Make WinMtfFontStyle's base class
EMFIO_DLLPUBLIC, too".
libcxxabi's __dynamic_cast takes static_type and dst_type arguments. Now, if
dst_type (the derived type, with default visibility) is taken from .so A (and
thus references the version of the base type info hidden in .so A) but the
__dynamic_cast call is made from .so B, it passes for static_type the base type
information hidden in .so B, and __dynamic_cast will consider the cast to fail.
I'm not sure whether hidden intermediary types (in the hierarchy between the
dynamic_cast's base and derived types) acutally cause a problem too, but lets
flag them with the plugin anyway.
The fixes use SAL_DLLPUBLIC_RTTI. For one, there appear to be no other reasons
than type visibility to make those classes SAL_DLLPUBLIC. For another, this
nicely avoids any actual changes on Windows (where SAL_DLLPUBLIC expands to
nothing, and many of the affected classes were explicityl introduced into class
hierarchies as "MSVC hacks").
Change-Id: Ia85a9635cebffb1009a9efc1484b8bd4025585d4
Reviewed-on: https://gerrit.libreoffice.org/41802
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
