[cfe-dev] Static analysis tool development

[Ted Kremenek]

On Jan 16, 2009, at 8:31 PM, Ryan Govostes wrote:

>> As an interesting side note, the developers of Adium (http://www.adiumx.com 
>> ) have actually been regularly scanning their sources using Clang's  
>> static analyzer.  As part of their process, they wrote some scripts  
>> that inspect the emitted diagnostics (in this case HTML files) and  
>> did some munging to determine if the a report emitted on a given  
>> scan was the same as in a prior scan.  Their goal is to avoid re- 
>> inspecting previously diagnosed bugs and false positives.  Having a  
>> general mechanism in the analyzer library would be quite useful,  
>> and would be a good first order project for anyone who is  
>> interested in getting involved.
>>
>
> I thought I'd chime in here; I wrote the scripts we currently use in  
> Adium for this purpose. Sources (which do not work with the latest  
> version of Clang, to my knowledge) are at:http://trac.adiumx.com/browser/trunk/Utilities/Analyzer
>
> In response to the above paragraphs of Ted's e-mail, I thought I'd  
> announce here that I've been working on a Trac plugin for viewing  
> Clang reports. Recent versions of the analyzer will output to plist  
> files, or HTML files, but not both (though this would presumably be  
> a trivial change). The Trac plugin parses plist files to generate a  
> file view, which is annotated with the appropriate diagnostics.

That's awesome!

> Using a dynamic view (i.e., the one generated by Trac) to view the  
> reports has some benefits over the static files. For one, we can  
> strip parts of the code that are irrelevant to the report, instead  
> showing only a few context lines above and below each diagnostic.  
> Another thing we can do is add links to other pages, such as a  
> report generated on a previous revision of the file.

I honestly would like to go to a completely dynamic view model.  This  
was the reason for introducing 'scan-view' to view error reports so  
that we could eventually move to this model completely.  The idea  
would be (more or less) to generate all error reports as plist files  
and then use clang on the side to generate syntax-highlighted HTML.   
This would be far more scalable; it would take less disk space (syntax- 
highlighted HTML files can get big) and it allows a diversity of  
rendering of the reports.  Of course we still want to support the  
model where we can get self-contained report files that users can  
attach to emails, etc., but a dynamic tracking system inherently  
allows us to do more things: track false positives and bugs across  
runs, measure interesting statistics, etc.

I personally think a Trac plugin is a great idea.  I would like to see  
some general infrastructure for building different dynamic interfaces  
(e.g., the Trac plugin, scan-view) to facilitate the construction of  
different interfaces that tailor to different tastes/workflows/ 
development processes.

> More importantly, however, is the possibility to automatically file  
> tickets based on new bugs. The system can track a single bug  
> longitudinally across several commits, using simple heuristics to  
> decide when a report has been resolved, or merely changed. (This  
> would integrate well with a system like Buildbot for performing scan  
> builds and uploading new plists.)
>
> Is there any interest in a plugin like this? I'd be glad to share it  
> on a repository if anyone would like to help flesh out the idea.

I personally wouldn't have much time to work on a Trac plugin, but I  
would love to see open development on this feature.  We can also link  
to it from the Clang web page.  Per my earlier statement, I would like  
to see some of the logic for tracking issues across runs put into a  
common library that could be used by multiple interfaces.  Some of  
this logic could be specific to a particular interface (e.g., Trac)  
while the rest of it would be more generic and reusable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090119/f090cc31/attachment.html>