look for classes which are effectively final, but contain protected
members. These members can be made private.
Change-Id: If53d535b068b668d1aff548ebfd0fe6c51a48a0e
(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>
This works at least with a recent Clang trunk (towards Clang 6.0).
In order for the plugin.dll to find the LLVM/Clang symbols, it needs to be
loaded into clang.exe not clang-cl.exe, so set CC/CXX to 'clang.exe
--driver-mode=cl ...'.
Buidling the plugin requires some linker flags that must go at the very end of
the COMPILER_PLUGINS_CXX command line, after a /link switch, so introduce
another COMPILER_PLUGINS_CXX_LINKFLAGS variable for that. Also, clang.lib is
not installed as part of LLVM's 'cmake --build ... --target install' step, so
is not available under CLANGDIR and needs to be taken from the build tree
instead, so introduce another CLANGLIBDIR variable for that. autogen.input
settings that work for me on Windows 8.1 with Microsoft Visual Studio 14.0 are:
> CLANGDIR=C:/llvm/inst
> CLANGLIBDIR=C:/llvm/build/lib
> COMPILER_PLUGINS_CXX=C:/PROGRA~2/MICROS~3.0/VC/bin/amd64/cl.exe /IC:\PROGRA~2\MICROS~3.0\VC\INCLUDE /IC:\PROGRA~2\MICROS~3.0\VC\ATLMFC\INCLUDE /IC:\PROGRA~2\WI3CF2~1\10\include\100102~1.0\ucrt /IC:\PROGRA~2\WI3CF2~1\NETFXSDK\46D346~1.1\include\um /IC:\PROGRA~2\WI3CF2~1\8.1\include\shared /IC:\PROGRA~2\WI3CF2~1\8.1\include\um /IC:\PROGRA~2\WI3CF2~1\8.1\include\winrt
> COMPILER_PLUGINS_CXX_LINKFLAGS=/LIBPATH:C:/PROGRA~2/MICROS~3.0/VC/LIB/amd64 /LIBPATH:C:/PROGRA~2/MICROS~3.0/VC/ATLMFC/LIB/amd64 /LIBPATH:C:/PROGRA~2/WI3CF2~1/10/lib/100102~1.0/ucrt/x64 /LIBPATH:C:/PROGRA~2/WI3CF2~1/NETFXSDK/46D346~1.1/lib/um/x64 /LIBPATH:C:/PROGRA~2/WI3CF2~1/8.1/lib/winv6.3/um/x64
(The last two are "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/
amd64/cl.exe" and translations of %INCLUDE% and %LIB% as set in the "VS2015 x64
Native Tools Command Prompt" shell.
AC_CHECK_HEADER(clang/AST/RecursiveASTVisitor.h, ...) in configure.ac wouldn't
like CXX to start with INCLUDE=... LIB=... environment variable settings, so it
wouldn't work to instead pass %INCLUDE% and %LIB% to cl.exe that way. See
<https://wiki.documentfoundation.org/Development/clang-cl> for general
information about building with clang-cl on Windows.)
There's still some room for improvement marked "TODO". (And some of the unused*
plugins, which are not run by default anyway, use Unix-style functionality, so
have been disabled for now.)
Change-Id: I6c28bdeb801af39ce2bae03111f455e2338d66c9
Reviewed-on: https://gerrit.libreoffice.org/42931
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so spell out its single use, locking the appropriate mutex around the access
Change-Id: I8e8f47de1979f5a80cf1ad65e5ec24d25145c463
Reviewed-on: https://gerrit.libreoffice.org/42908
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...about the definition of __cxxabiv1::__cxa_exception in
bridges/source/cpp_uno/gcc3_linux_x86-64/share.hxx, when a declaration of that
struct has already been seen in /usr/include/c++/7/cxxabi.h in a
#pragma GCC visibility push(default)
...
#pragma GCC visibility pop
block (so that decl->getAttr<VisibilityAttr>() would point at the first of those
two pragmas).
Change-Id: I4af56be8ce84ace57a809a09da5c44d86fc4237a
...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>
