There are some problems here, this should fix one of them: the
getFilename function returns "<stdin>" for spelling locations, because
the input to clang is sort of preprocessed via -frewrite-includes if
icecream is used and the file is built on a remote host (whereas it's
apparently not preprocessed if the file is compiled locally by icecream).
Using getPresumedLoc() uses the #line directives in the preprocessed
input, which avoids the problem but is more expensive, so try to use it
only when necessary.
The getFileEntry(getMainFileID())->getName() pattern will also result
in "<stdin>", but fortunately icecream passes -main-file-name,
which oddly enough isn't used by the SourceManager's spelling locations,
but is available separately via CodeGenOptions.
This builds everything successfully with clang version 6.0.0:
ICECC_PREFERRED_HOST=myremote make check gb_SUPPRESS_TESTS=t
Change-Id: Ic121511683e5302d7b9d85186c8b9c4a5443fa1b
Reviewed-on: https://gerrit.libreoffice.org/54993
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
...mostly of C-style casts among arithmetic types, and automatically rewrite
those into either static_cast or a functional cast (which should have identical
semantics, but where the latter probably looks better for simple cases like
casting a literal to a specific type, as in "sal_Int32(0)" vs.
"static_cast<sal_Int32>(0)").
The main benefit of reducing the amount of C-style casts across the code base
further is so that other plugins (that have not been taught about the complex
semantics of C-style cast) can pick those up (cf. the various recent
"loplugin:redundantcast" commits, which address those findings after this
improved loplugin:cstylecast has been run). Also, I found some places where
a C-style cast has probably been applied only to the first part of a larger
expression in error (because it's easy to forget parentheses in cases like
"(sal_uInt16)VOPT_CLIPMARKS+1"); I'll follow up on those individually.
The improved loplugin:cstylecast is careful to output either "(performs:
static_cast)" or "(performs: functional cast)", so that
compilerplugins/clang/test/cstylecast.cxx can check that the plugin would
automatically rewrite to one or the other form.
To allow fully-automatic rewriting, this also required loplugin:unnecessaryparen
to become a rewriting plugin, at least for the parens-around-cast case (where
"((foo)bar)" first gets rewritten to "(static_cast<foo>(bar))", then to
"static_cast<foo>(bar)". Rewriting could probably be added to other cases of
loplugin:unnecessaryparen in the future, too.
(The final version of this patch would even have been able to cope with
361dd2576a "Replace some C-style casts in ugly
macros with static_cast", so that manual change would not have been necessary
after all.)
Change-Id: Icd7e319cc38eb58262fcbf7643d177ac9ea0220a
Reviewed-on: https://gerrit.libreoffice.org/47798
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...as those may be used to silence Clang -Werror,-Wunreachable-code (as happens
in sal/osl/unx/file_volume.cxx for Android, where OSL_detail_STATFS(...) always
expands to (1)).
Change-Id: I85d280c1315b4447362255d17f13f437d3c4af92
...that are not composed of multiple tokens, like ("foo" "bar"). Also don't yet
warn about Boolean literals, which are sometimes wrapped in parentheses to
silence unreachable-code warnings.
To avoid multiple warnings about code like
f((0))
switch to generally using a set of ParenExpr to keep track of which occurrences
have already been handled.
Change-Id: I036a25a92836ec6ab6c56ea848f71bc6d63822bc
Reviewed-on: https://gerrit.libreoffice.org/45317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* rsc/source/parser/rscyacc.cxx no longer exists
* writerfilter/source/rtftok/rtftokenizer.cxx appears to be just fine nowadays?
* sw/source/filter/html/htmltab.cxx used redundant parentheses around a comma
operator in a while condition, and I see no reason not to remove them (the
result requires a---reasonable---tweak to loplugin:commaoperator, though)
Change-Id: I451132c700b0ae5a43b03d704156484df897ad5c
Reviewed-on: https://gerrit.libreoffice.org/45213
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which had been left out because "lots of our code uses this style, which I'm
loathe to bulk-fix as yet", but now in
<https://gerrit.libreoffice.org/#/c/45060/1/> "use std::unique_ptr" would have
caused an otherwise innocent-looking code change to trigger a
loplugin:unnecessaryparen warning for
pFormat = (pGrfObj)
? ...
(barring a change to ignoreAllImplicit in
compilerplugins/clang/unnecessaryparen.cxx similar to that in
<https://gerrit.libreoffice.org/#/c/45083/2> "Make not warning about !! in
loplugin:simplifybool consistent", which should also have caused the warning to
disappear for the modified code, IIUC).
Change-Id: I8bff0cc11bbb839ef06d07b8d9237f150804fec2
Reviewed-on: https://gerrit.libreoffice.org/45088
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
81892b2037 "loplugin:unnecessaryparen when
compiling as C++17, so the ParenExpr is no longer hidden behind
ExprWithCleanups/CXXConstructExpr/MaterializedTemporaryExpr wrappers" gave me
the idea to generally look though IgnoreImplicit instead of IngoreImpCasts in
loplugin:unnecessaryparen. However, that would still not look through implicit
CXXConstructExpr, so would still not have found the occurrences in
81892b2037 when compiling in pre-C++17 mode.
Therefore, let ignoreAllImplicit also look through CXXConstructExpr. (I am not
entirely sure in which situations non-implicit CXXConstructExpr---that should
thus not be ignored---would occur, but assume they would be underneath something
like a CXXFunctionalCastExpr, which is not ignored.)
Change-Id: I947d08742e1809150ecc34a7abe84cca5e0ce843
...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>
