summaryrefslogtreecommitdiff
path: root/compilerplugins/clang/unnecessaryparen.cxx
AgeCommit message (Collapse)Author
2018-07-06compilerplugins: try to make these work with icecreamMichael Stahl
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>
2018-01-17loplugin:unnecessaryparen extend to delete statementsNoel Grandin
Change-Id: Ic4383ea948876a26f791f0e5b0110cef978a26e1 Reviewed-on: https://gerrit.libreoffice.org/48027 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-01-16Fix typosAndrea Gelmini
Change-Id: I46873c8bea3bbfeebb7dee50918d3978408fcf63 Reviewed-on: https://gerrit.libreoffice.org/47842 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2018-01-12Enable loplugin:cstylecast for some more casesStephan Bergmann
...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 361dd2576a09fbda83f3ce9a26ecb590c38f74e3 "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>
2017-12-29loplugin:unnecessaryparen improve return checkNoel Grandin
Change-Id: I8128aa4b5fc60efd1dbf5971cdde11e588f5f64b Reviewed-on: https://gerrit.libreoffice.org/47167 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-30loplugin:unnecessaryparen: signed numeric literalsStephan Bergmann
Change-Id: I75c8224452ca9c3711a2ccaca9ecf549fa59cb64 Reviewed-on: https://gerrit.libreoffice.org/45549 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-11-30Enable loplugin:unnecessaryparen for integer and Boolean literalsStephan Bergmann
...taking care not to warn about those cases that are used to silence Clang's -Wunreachable-code Change-Id: I3c1da907f51cc786f81c1322fe71d75832cd9191 Reviewed-on: https://gerrit.libreoffice.org/45521 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-11-28Revert loplugin:unnecessaryparen warning around integer literalsStephan Bergmann
...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
2017-11-27loplugin:unnecessaryparen: Warn about parentheses around literalsStephan Bergmann
...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>
2017-11-27loplugin:unnecessaryparen check for (f1()).f2Noel Grandin
Change-Id: I93257b0ddd41c649875124d6d5c5faeaa431bae3 Reviewed-on: https://gerrit.libreoffice.org/45218 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-24Clean up loplugin:unnecessaryparen blacklistStephan Bergmann
* 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>
2017-11-23Make loplugin:unnecessaryparen look through implicitStephan Bergmann
...similar to how <https://gerrit.libreoffice.org/#/c/45083/2> "Make not warning about !! in loplugin:simplifybool consistent" does for loplugin:simplifybool Change-Id: I23eef400af71c582d380c9bae6546ce06e8a1e18 Reviewed-on: https://gerrit.libreoffice.org/45122 Tested-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-11-22Make loplugin:unnecessaryparen warn about (x) ? ... : ... after allStephan Bergmann
...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>
2017-11-22There appears to be no reason to ignore macros in these parts of...Stephan Bergmann
...loplugin:unnecessaryparen Change-Id: I473a1e16cf9f485a61af5477aca22798996253a3
2017-11-20look for =() in loplugin:unnecessaryparenNoel Grandin
Change-Id: I4f9b71ff7767e90987bb40358fc46ed5d1d571d0 Reviewed-on: https://gerrit.libreoffice.org/44944 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-07Clean away temporarily added using declarationsStephan Bergmann
Change-Id: I26734c13515394162d88351a1cbe2b20abdac865
2017-10-26More loplugin:unnecessaryparenStephan Bergmann
81892b2037453108b9bde1512a500cf3b2ce438a "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 81892b2037453108b9bde1512a500cf3b2ce438a 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
2017-09-13Enable -Wunreachable-codeStephan Bergmann
...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>
2017-09-06loplugin:unnecessaryparen include case statementsNoel Grandin
Change-Id: I79fb3eec0d5d466e33b2e18621a7169695edf82f Reviewed-on: https://gerrit.libreoffice.org/41920 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-09-04loplugin:unnecessaryparen include c++ castsNoel Grandin
Change-Id: I132d3c66f0562e2c37a02eaf4c168d06c2b473eb Reviewed-on: https://gerrit.libreoffice.org/41874 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-08-18loplugin:unnecessaryparenNoel Grandin
look for statements like return (function()); Change-Id: I906cf2183489f87225b99b987caca67e39b26cc3 Reviewed-on: https://gerrit.libreoffice.org/41260 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-16lopgluin:unnecessaryparen: Properly treat parenthesized sub-expr in sizeof (x)Stephan Bergmann
...where redundant parentheses are probably common enough to not warn about them Change-Id: Ia88097f5d3433e03337d6d42a144abfe210733c2
2017-07-13Use isSamePathname for full-pathname comparisonsStephan Bergmann
Change-Id: Iccc20f441aceae7c6bcdf3a24d2a42ec9be8bb8f
2017-07-10teach unnecessaryparen loplugin about identifiersNoel Grandin
Change-Id: I5710b51e53779c222cec0bf08cd34bda330fec4b Reviewed-on: https://gerrit.libreoffice.org/39737 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-07loplugin:unnecessaryparen handle parens inside call exprNoel Grandin
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>
2017-07-06teach unnecessaryparen plugin about other kinds of statementsNoel Grandin
i.e. do / while / switch Change-Id: Id0985015cc425557f9984734701d56466f8a6088 Reviewed-on: https://gerrit.libreoffice.org/39601 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-06loplugin unnecessaryparan improvementsNoel Grandin
Change-Id: I73e945d6ec53537a0da45f6b6291018c7f251a7e Reviewed-on: https://gerrit.libreoffice.org/39587 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-05new loplugin unnecessaryparenNoel Grandin
Change-Id: Ic883a07b30069ca6342d7521c8ad890f4326f0ec Reviewed-on: https://gerrit.libreoffice.org/39549 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-02-19 00:01:26 +0000