llvm dev - May 2019 - Trunk scan-build reports

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.

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>