(unless as the callee of a function call). In response to
<https://gerrit.libreoffice.org/#/c/42912/> "DO NOT MERGE - error in clang
static plugin". Many of the whitelisted functions can now be taken off the
list.
Change-Id: I04c2ee445e7973a288f42fd663d8b2d78cd3c5aa
Reviewed-on: https://gerrit.libreoffice.org/42958
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
...as needed by clang-cl on Windows to avoid unhelpful warnings about
OleEmbeddedObject::changeState (embeddedobj/source/msole/oleembed.cxx)
containging an "if" in an "#ifdef _WIN32" block followed by "else throw".
Change-Id: I95bed29b9003db08499156ae7f885aeeea5a0158
Reviewed-on: https://gerrit.libreoffice.org/42963
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
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>
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>
that can use std::unique_ptr, and apply it in i18npool
Change-Id: Ib410abaf73d5f392c7a7a9a322872b08c948f9e9
Reviewed-on: https://gerrit.libreoffice.org/41438
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
The code in SvXMLExportItemMapper::exportXML was broken as far back as
its introduction in
commit 0c28e3c480a95c03b513c55f029b979bcd9c0401
"Move SvXMLAttrContainerItem to SVX, moved writer only code to sw"
Change-Id: I90043ce8b7263aa56fd0883d350e29b97eeaf99b
Reviewed-on: https://gerrit.libreoffice.org/41282
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
makes writing nice code awkward sometimes.
Also split plugin into two different plugins, the logic was getting
tangled up.
Change-Id: I232e314d29c766c160c29373988dc37a466505be
<sberg> noelgrandin, and is loplugin:deadclass even sound?
struct B { B(B const &) {} }; struct D: B { D(): B(*this) {} };
Change-Id: Idadd379b925aa6f9de6c625bffa8560ec4192ac7
The types 'long' and 'unsigned long' are different sizes on different
platforms, making them wholy unsuitable for portable code.
And when I mean different sizes, I mean 64bit Linux and 64bit Windows
have different bit sizes.
Change-Id: Id4d8cd709bf71a3f85ed6515fae2b0a21ae8c25d
Reviewed-on: https://gerrit.libreoffice.org/41130
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
look for classes which only have copy/move constructors, and so are
effectively dead
Change-Id: I0b844f301e2200c2b40031856bfdb0b0e2c8f77d
Reviewed-on: https://gerrit.libreoffice.org/41039
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
extend oncevar to any POD type
Change-Id: Ia98ee0a67f183e40fb0c38477760124b2c411dc0
Reviewed-on: https://gerrit.libreoffice.org/40564
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
had to change the structure of the plugin considerably, was too messy to
structure it to do the calculations on a per-function basis
Change-Id: I4edee7735f726101105c607368124a08dba21086
Reviewed-on: https://gerrit.libreoffice.org/40516
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(Where the change to basic/source/comp/codegen.cxx reveals that
loplugin:loopvartoosmall also needs the Clang < 3.9 workaround from
33ee8e61292af05627f5f72ea2f93ad80e715e46 "Work around bug in Clang 3.8".)
Change-Id: I9f23b9648bc11ca4136a0fbdd332570ba70ee77c
Reviewed-on: https://gerrit.libreoffice.org/39667
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
stick to single-arg function calls, sometimes parens in multi-arg calls
might be there for clarity
Change-Id: Ib80190c571ce65b5d219a88056687042de749e74
Reviewed-on: https://gerrit.libreoffice.org/39676
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
found a couple more by running
make build-nocheck
to exclude testing code
Also, teach unusedfields loplugin about operator<<, since
referring to a field in an ostream operator<< does not indicate a
real use, it's normally for debugging
Change-Id: I3dce22bf5afda2fd09e01de9bf1d0ef85e535aa8
Reviewed-on: https://gerrit.libreoffice.org/39625
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to find ref-counted classes being managed via other smart pointer
classes.
Hopefully prevent needing fixes like
642ae256ea5b8083ba0b3c097ca8ea52304b9cdb
"ChangedUIEventListener is refcounted, mustn't be helt by unique_ptr"
Change-Id: I6b0c5f8f87ce3546a8a1104ce1000470c09459bd
Reviewed-on: https://gerrit.libreoffice.org/39378
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
