[llvm-dev] Trunk scan-build reports

[Simon Pilgrim via llvm-dev]

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.