summaryrefslogtreecommitdiff
path: root/compilerplugins/clang/unnecessaryparen.cxx
AgeCommit message (Collapse)Author
2020-04-11Adapt loplugin:unnecessaryparen to C++20 CXXRewrittenBinaryOperatorStephan Bergmann
...as is used by GCC trunk libstdc++ std::unique_ptr since <https://gcc.gnu.org/ git/?p=gcc.git;a=commitdiff;h=5b074864f8c593fd4bccee788a023a37b446b2ed> "libstdc++: Add comparison operators to std::unique_ptr", which caused unexpected warnings like > sfx2/source/dialog/tabdlg.cxx:1057:17: error: parentheses immediately inside vardecl statement [loplugin:unnecessaryparen] > bool bSet = ( m_pSet != nullptr ); > ^~~~~~~~~~~~~~~~~~~~~ (CXXRewrittenBinaryOperator was introduced with <https://github.com/llvm/ llvm-project/commit/778dc0f1d49230f53401ae0c190fe460bda4ffd1> "[c++20] Add CXXRewrittenBinaryOperator to represent a comparison", which first appeared in LLVM 10.) Change-Id: I68024d975dc4accbfa9da855baa37bf9f990b99c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92061 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-30...and take implicit const casts into accountStephan Bergmann
...following up on 4f8a744c4fcf2c69462af19bd807fee32413158d "Make loplugin:unnecessaryparen treat member expressions consistently" Change-Id: I444d2995e88990c3c6fa2b912ef68032daf2cad9 Reviewed-on: https://gerrit.libreoffice.org/84112 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-29Make loplugin:unnecessaryparen treat member expressions consistentlyStephan Bergmann
Stumbled across a warning starting to get emitted for some !(p->x) when I temporarily changed x from boost::optional (which has a member operator!) to std::optional (which instead implicitly uses a member conversion operator to bool). (That is, for the new static int foo3(Foo2 & foo) { (void) !(foo.p); (void) !(foo.b); (void) !(foo.n); return (foo.p) ? 1 : 0; } test, the first, third, and fourth body lines never warned, while the second one erroneously warned without this fix.) Change-Id: I60f6941aaa3a73db0f1373c954e47aa68d703170 Reviewed-on: https://gerrit.libreoffice.org/84079 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-26Adapt to clang::MaterializeTemporaryExpr::GetTemparyExpr renameStephan Bergmann
...in <https://github.com/llvm/llvm-project/commit/ b0561b3346e7bf0ae974995ca95b917eebde18e1> "[NFC] Refactor representation of materialized temporaries" Change-Id: I02fbf6765f9713e4d457f07521129cc9d8db5751 Reviewed-on: https://gerrit.libreoffice.org/83669 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-03-12make (some) clang plugins share the same RecursiveASTVisitorLuboš Luňák
Each plugin currently uses its own recursive AST run, which adds up. This patch adds another shared plugin which internally contains all (suitable) plugins and dispatches to them from the same one recursive run. This patch converts ~25 plugins and for starmath's accessibility.cxx reduces clang build time from 5.43s to 5.14s (and it's 4.39s without any plugins). As there are almost 50 more plugins to go, this can theoretically result in 4.56s final time, although probably not all plugins can be that easily converted, if at all. This mostly requires very little change in many plugins (see e.g. BadStatics), some even work without any functionality change (e.g. CharRightShift). Traverse* calls require some changes but are often not that difficult. WalkUp* probably can't be supported, although some plugins can(?) possibly be adjusted to not rely on them. And of course some plugins can be left as they are, using their own recursive run. See description at the top of generator.cxx for description of how to convert a plugin. The sharedvisitor.cxx source is generated based on scanning relevant plugin sources using a clang-based scanner/generator. The generated source is intentionally included instead of getting always generated, as the generating currently takes some time, so it should get updated in git whenever a change in a plugin triggers a source change in it. Change-Id: Ia0d2e3a5a464659503dbb4ed6c20b6cc89b4de01 Reviewed-on: https://gerrit.libreoffice.org/68026 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-03-06loplugin:unnecessaryparen improve member expressionNoel Grandin
Change-Id: I304621018cb1e2a47e478e86df4229bcf2176741 Reviewed-on: https://gerrit.libreoffice.org/68757 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-02-19Better loplugin:unnecessaryparen check for vexing parseStephan Bergmann
Change-Id: Id7b09a8556da25b81c056d5811ba721e781682d6 Reviewed-on: https://gerrit.libreoffice.org/68025 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-05loplugin:unnecessaryparen include more assignmentsNoel Grandin
Change-Id: I9fb8366634b31230b732dd38a98f800075529714 Reviewed-on: https://gerrit.libreoffice.org/64510 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-11-12Adapt to new ConstantExpr in Clang trunk towards Clang 8Stephan Bergmann
After <https://reviews.llvm.org/D53921> "Compound literals, enums, et al require const expr" (making use of ConstantExpr recently introduced with <https://reviews.llvm.org/D53475> "Create ConstantExpr class", CompilerTest_compilerplugins_clang started to fail with > [CPT] compilerplugins/clang/test/unnecessaryparen.cxx > error: 'error' diagnostics expected but not seen: > File /data/sbergman/lo-clang2/core/compilerplugins/clang/test/unnecessaryparen.cxx Line 35: parentheses immediately inside case statement [loplugin:unnecessaryparen] > error: 'error' diagnostics seen but not expected: > File /data/sbergman/lo-clang2/core/compilerplugins/clang/test/unnecessaryparen.cxx Line 35: unnecessary parentheses around identifier [loplugin:unnecessaryparen] > 2 errors generated. Change-Id: Iebcfcd9af30e26df02819fbffb105599fa6a1701 Reviewed-on: https://gerrit.libreoffice.org/63285 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-08-23filter out AST in more pluginsNoel Grandin
I seem to have missed quite a few in commit 9f4d23c15115d64febd6bf01f870cc157badd350 filter out some of the AST in the plugins This nets me another 14% improvement Change-Id: I39b980b49ced560f768045dbedd3ddfef29306c1 Reviewed-on: https://gerrit.libreoffice.org/59501 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-10Avoid -Werror=deprecated-declarations with recent Clang trunkStephan Bergmann
...which first added alternative names to and then deprecated getLocBegin/End Change-Id: Iaefb8ce259057abfa6cd20f0b63c0ef2949a96b2 Reviewed-on: https://gerrit.libreoffice.org/58820 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-05-12 06:31:32 +0000