and fix bug in ScriptDocument::getTitle
which has been there since
commit e304ba66f4
Date: Thu Mar 15 14:59:30 2007 +0000
INTEGRATION: CWS basmgr02 (1.1.2); FILE ADDED
plugin is off by default since it uses expensive parentStmt() calls
Change-Id: Id0f16baec48e0381e0083594d7e59b58b023da2f
Reviewed-on: https://gerrit.libreoffice.org/43750
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...that the compiler is free to elide anyway. (See
4e7ffc0a69 "Avoid compiler eliding#redundant
dynamic_cast" and 380d6afe5f "Remove redundant
asserts involving dynamic_cast".)
Change-Id: I3f75154fee3e978b7ba95a5a27589417065599bd
...by avoiding calls to parentStmt, thereby also improving the precision of
exactly which comma operators to ignore (which turned up a handful more finds).
Also added tests.
Change-Id: Ie74f824fd7f54131aab09b59086452fb4f3ff827
Reviewed-on: https://gerrit.libreoffice.org/43181
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...invovling preprocessing conditionals, to actually make the unhelpful warning
on Windows about OleEmbeddedObject::changeState go away. And while at it, make
the check for preprocessing conditionals more targeted (similar to
1084e8be44 "More targeted check for preprocessing
conditionals in loplugin:blockblock").
Change-Id: I0300e0a547e969520a90cd126ea8f788cc17560f
Reviewed-on: https://gerrit.libreoffice.org/42975
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...as needed to avoid an unhelpful warning about Player::createPlayerWindow in
avmedia/source/gstreamer/gstplayer.cxx when included from
avmedia/source/gstreamer/gst_0_10.cxx (so that ENABLE_GTKSINK is not defined).
Change-Id: I6de9cc59cf8e611c4c9d939dd837499b1d2c8787
...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
...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>
The code in SvXMLExportItemMapper::exportXML was broken as far back as
its introduction in
commit 0c28e3c480
"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>
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
33ee8e6129 "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>
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>
