[cfe-dev] [GSoC 2019] Apply the Clang Static Analyzer to LLVM-based projects - final report

Artem Dergachev via cfe-dev cfe-dev at lists.llvm.org
Wed Aug 28 16:02:35 PDT 2019


Yay thx!

Sylvestre, is there anything i can help you with in order to get the 
reports page back up?

I'd also indeed love to spam people with warnings that they introduced, 
even if in the form of a weekly summary. We already have scripts that 
compare scan-build outputs, but we mostly use them for testing the 
analyzer itself.


 > Improving documentation (and support scripts) on how to get a 
analyzer report on local builds

Yup, i guess we could write something up.

LLVM isn't very special when it comes to running the analyzer, so it 
normally boils down to the official documentation in 
http://clang-analyzer.llvm.org/scan-build.html - as in:

   $ scan-build cmake ../llvm -G Ninja -DLLVM_ENABLE_ASSERTIONS=1 
$YOUR_CUSTOM_FLAGS
   $ scan-build ninja

(running cmake under scan-build as veeeeery vaguely hinted in 
http://clang-analyzer.llvm.org/scan-build.html#recommended_autoconf is 
indeed necessary; it should also be roughly equivalent to 
-DCMAKE_C_COMPILER_LAUNCHER=ccc-analyzer 
-DCMAKE_CXX_COMPILER_LAUNCHER=c++-analyzer)

I'm fairly ignorant about Windows specifics though.


On 8/28/19 1:07 AM, Simon Pilgrim wrote:
> Sylvestre Ledru looks after the scan-build web report, but I 
> understand it hit a few issues back in June (it normally updates a few 
> times a week). We also discussed whether there was an automated way 
> for those updates to email the summary to the cfe/llvm dev lists, 
> indicating total warnings, and highlighting any new ones (we punted 
> that discussion until the GSoC was done - btw thank you all!!!).
>
> Improving documentation (and support scripts) on how to get a analyzer 
> report on local builds would be very useful - I've found it tricky to 
> work with on my WSL builds and I tended to just browse the scan-build 
> web report when it was up to date. At the moment I'm just keeping an 
> eye on cppcheck and MSVC analysis reports that I have running in 
> visual studio.
>
> On 28/08/2019 02:56, Artem Dergachev wrote:
>> +Simon because he has enthusiastically looked at the state of things 
>> just before we started: 
>> http://lists.llvm.org/pipermail/llvm-dev/2019-May/132196.html
>>
>> Also +Devin.
>>
>> Also, Simon: do you know how does 
>> https://llvm.org/reports/scan-build/ usually get updated? It doesn't 
>> seem to be in the www repo and it's now super outdated, given the 
>> amount of change that Csaba unleashed upon us this summer.
>>
>> I suggest that from now on we pay more attention to these reports, 
>> because even though there are still a lot of them, and still 
>> definitely not all of them constitute real crashes, they make *much* 
>> more sense today than they used to some three months ago. Almost all 
>> warnings are actionable and promote better, safer code.
>>
>> I just spent 2-3 hours cleaning up ~20 warnings on the static 
>> analyzer itself, which included writing a test for one real crash 
>> that i found that way (and attempting to do the same for a few more 
>> potential crashes). The results are in 
>> https://reviews.llvm.org/D66847. My (heavily biased) opinion is that 
>> it was worth every minute and i basically encourage everybody to try 
>> this out again.
>>
>>
>> On 8/26/19 10:23 AM, Csaba Dabis wrote:
>>> Hey everyone!
>>>
>>> This Summer we managed to make the Clang Static Analyzer support the 
>>> LLVM and
>>> LLVM-based projects with my mentors Artem Dergachev and Gabor Horvath.
>>>
>>> For a more detailed documentation please visit my final report:
>>> https://docs.google.com/document/d/1o9-xEWbzivUGKIOXp9jUNZYq0mkecd5KH5dBN5Hdlu8/ 
>>>
>>>
>>> The project in a nutshell: I have fixed the most annoying false 
>>> positives and
>>> added support for the custom RTTI of LLVM which became a huge true 
>>> positive
>>> boost as we now emit warnings on misuse of LLVM casting APIs. All of 
>>> my patches
>>> (except one D65239) are upstreamed and on by default. The remaining 
>>> work is to
>>> fix the less annoying and not so common false positives.
>>




More information about the cfe-dev mailing list