summaryrefslogtreecommitdiffstats
path: root/compilerplugins/clang/expressionalwayszero.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Don't try to evaluate value of value-dependent ExprStephan Bergmann2019-05-221-1/+1
| | | | | | | | | | | ...which causes asserts to fire since <https://github.com/llvm/llvm-project/ commit/04323c24a1ac9464471331d9f6499d3cb95d1ccd> "Added an assertion to constant evaluation enty points that prohibits …" Change-Id: Iafbf1cea85d15a38a71275d4cea8303bab500f6a Reviewed-on: https://gerrit.libreoffice.org/72723 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* use more hasPathnamePrefixNoel Grandin2019-02-111-11/+7
| | | | Change-Id: I539e6aedad61d80b6ebe80104b77d720072395bd
* add EvaluateAsInt compat function for latest clangNoel Grandin2018-11-271-1/+1
| | | | | | | | | the old EvaluateAsInt method has been dropped as from current clang Change-Id: Ie30d1547ad8de777badff4b380d2fc9fb261e8fe Reviewed-on: https://gerrit.libreoffice.org/64107 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Always disable loplugin:expressionalwayszero, to avoid false positivesStephan Bergmann2018-09-221-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | bdade7e3fc33c1832c6f6a472443fca8238738d2 "tdf#105444 DOCX import: don't put extra paragraphs in comments" caused > /home/sbergman/lo2/core/writerfilter/source/dmapper/DomainMapper_Impl.cxx:441:22: error: expression always evaluates to zero, lhs=0 rhs=unknown [loplugin:expressionalwayszero] > (sizeof(SAL_NEWLINE_STRING)-1 == 2 && xCursor->getString() == "\n")) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ now with sufficiently new Clang, and the code looks reasonable, and there's no apparent way to avoid such false positives in the plugin. (It could check for a sub-expression of the problematic expression being an object-like macro, but SAL_NEWLINE_STRING could just as well be a variable instead of a macro. That variable would need to be defined in some #if to have different values on different platforms, so the plugin could theoretically check for such conditional inclusion, but it's not clear whether that's worth it and would even be a useful heuristic to not produce neither too many false positives nor too many false negatives.) So just disable the plugin for good. Change-Id: I85dc8573735ccac4e19be20ab7443cbaa85a3164 Reviewed-on: https://gerrit.libreoffice.org/60907 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* filter out AST in more pluginsNoel Grandin2018-08-231-2/+2
| | | | | | | | | | | | | | 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>
* Avoid -Werror=deprecated-declarations with recent Clang trunkStephan Bergmann2018-08-101-4/+4
| | | | | | | | | ...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>
* compilerplugins: try to make these work with icecreamMichael Stahl2018-07-061-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Don't warn about multiplication by zero in loplugin:expressionalwayszeroStephan Bergmann2018-04-231-18/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | That specific warning (added with 862dc17e437f0972223e18555110dc875d2ffa44 "loplugin:expressionalwayszero improvements", together with other improvements) already looked somewhat unhelpful to me in 4cb78942f25e9ea2e9a8445825438cd67b1c00f9 "loplugin:expressionalwayszero (clang-cl)", but now started to generate > [CXX] vcl/source/bitmap/BitmapSobelGreyFilter.cxx > /data/sbergman/lo-clang2/core/vcl/source/bitmap/BitmapSobelGreyFilter.cxx:92:34: error: expression always evaluates to zero, lhs=0 rhs=unknown [loplugin:expressionalwayszero] > nSum1 += nMask121 * nGrey12; > ^~~~~~~~~~~~~~~~~~ > /data/sbergman/lo-clang2/core/vcl/source/bitmap/BitmapSobelGreyFilter.cxx:99:34: error: expression always evaluates to zero, lhs=0 rhs=unknown [loplugin:expressionalwayszero] > nSum2 += nMask212 * nGrey21; > ^~~~~~~~~~~~~~~~~~ > /data/sbergman/lo-clang2/core/vcl/source/bitmap/BitmapSobelGreyFilter.cxx:101:34: error: expression always evaluates to zero, lhs=0 rhs=unknown [loplugin:expressionalwayszero] > nSum1 += nMask221 * nGrey22; > ^~~~~~~~~~~~~~~~~~ > /data/sbergman/lo-clang2/core/vcl/source/bitmap/BitmapSobelGreyFilter.cxx:102:34: error: expression always evaluates to zero, lhs=0 rhs=unknown [loplugin:expressionalwayszero] > nSum2 += nMask222 * nGrey22; > ^~~~~~~~~~~~~~~~~~ > /data/sbergman/lo-clang2/core/vcl/source/bitmap/BitmapSobelGreyFilter.cxx:105:34: error: expression always evaluates to zero, lhs=0 rhs=unknown [loplugin:expressionalwayszero] > nSum2 += nMask232 * nGrey23; > ^~~~~~~~~~~~~~~~~~ > /data/sbergman/lo-clang2/core/vcl/source/bitmap/BitmapSobelGreyFilter.cxx:110:34: error: expression always evaluates to zero, lhs=0 rhs=unknown [loplugin:expressionalwayszero] > nSum1 += nMask321 * nGrey32; > ^~~~~~~~~~~~~~~~~~ > 6 errors generated. (where all those nMask* are zero constants; and which even passed Gerrit/Jenkins as loplugin:expressionalwayszero is only active for Clang >= 3.9). Lets just remove that specific check again. Change-Id: Ia8710f83b16d6e6949439d3941e17b8a0959aa8b
* disable expressionalwayszero loplugin on clang-3.8Noel Grandin2018-03-291-0/+5
| | | | | | | | | can generate OOM Change-Id: Ie9fbed147687c06727a702616764a18d91b38e9c Reviewed-on: https://gerrit.libreoffice.org/52052 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
* loplugin:expressionalwayszero improvementsNoel Grandin2018-03-271-8/+56
| | | | | | | Change-Id: I00bdbc58d2295a0be30b47c85eae6b9abfec17b2 Reviewed-on: https://gerrit.libreoffice.org/51868 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Clean away temporarily added using declarationsStephan Bergmann2017-11-071-2/+2
| | | | Change-Id: I26734c13515394162d88351a1cbe2b20abdac865
* don't use boost in compilerpluginsNoel Grandin2017-08-181-7/+6
| | | | Change-Id: Ic1610e99cd2d11d1a536a6f3e66b44417ee59793
* new loplugin:expressionalwayszeroNoel Grandin2017-08-181-0/+123
The code in SvXMLExportItemMapper::exportXML was broken as far back as its introduction in commit 0c28e3c480a95c03b513c55f029b979bcd9c0401 "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>
generated by cgit (git 2.34.1) at 2024-05-26 23:50:51 +0000