[llvm-dev] Trunk scan-build reports

[Artem Dergachev via llvm-dev]

Hey Simon,

This year we'll be firing up a whole GSoC project to clean up these 
Static Analyzer false positives:

[1] http://llvm.org/OpenProjects.html#analyze-llvm
[2] http://lists.llvm.org/pipermail/cfe-dev/2019-April/061971.html

> Following the recent PVS Studio analysis of LLVM 8 (see
> https://bugs.llvm.org/show_bug.cgi?id=41655) I took a look at the
> current status of the scan-build CI against trunk:
> https://llvm.org/reports/scan-build/  to see how many of these we should
> already have known about.
>
> As of the build on Sunday May 5 (svn359972) we have 935 bugs in the
> report (with only a vague overlap with the issues mentioned in the PVS
> Studio article but they are quite selective on the bugs they put in the
> blog article).
>
> Looking through the scan-build report's links, I can understand why we
> may not have been vigilant at investigating many of these - a lot appear
> to be false positives, but to be honest many are trivial to avoid
> (better initialization, assertions etc.). I've committed a few NFCs that
> cleanup things here and there, but it'd be better to get code owners and
> people invested in particular areas of the code to take a look and
> decide if they are worth a NFC tweak; show an actual issue (in the code
> or static analyzer itself); or can just be ignored (possibly add a
> comment to the code to note the warning?).
>
> Refactoring code just to appease a static analysis isn't often a good
> policy, but I do think we should be doing more to improve things here.
>
> Particular areas of concern:
>
> 1 - the inevitable nullptr/dereference warnings - there always seems to
> be a particular (weird? impossible?) logic path that allows these cases
> - we have so many of these that separating the real bugs from the
> impossible cases is a major undertaking.
> 2 - bad use of std::move - use of the variable after it has been moved
> is particularly common and suggests a lack of understanding of what
> std::move does.
> 3 - use of uninitialized variables (or static analyzer thinks it is
> uninitialized).
>
> I'd really like to get some idea of how much an issue the community
> think this is or whether I'm just tilting at windmills.......
>
> Cheers, Simon.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190508/590caba6/attachment.html>