[clang-tools-extra] r194707 - Make clang's static analyzer checks available through clang-tidy.

[Anna Zaks]

On Nov 15, 2013, at 9:28 AM, Manuel Klimek <klimek at google.com> wrote:

> On Fri, Nov 15, 2013 at 6:25 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> On Nov 15, 2013, at 3:24 , Manuel Klimek <klimek at google.com> wrote:
> 
>> While I’m always happy when the analyzer gets more use, the text mode is something we haven’t ever really supported or worked on productizing—it’s always been a lo-fi output format that’s not guaranteed for anything besides debugging. Shipping a tool that reports paths in text mode is a big step, and there could easily be QoI issues we haven’t had to care about until now. (Also, sometimes paths are dozens of notes long.)
>> 
>> I'm not too concerned about this - we had Pavel running the static analyzer on all our code, outputting to text format, and analyzing the results, and I don't remember the text format ever being an issue. I don't really have a good idea what other format we'd want to use - our main use case is overlaying the warnings in various steps of our workflow.
>> 
>> If we run into problems with the static analyzer's text output, and you say it's not mean to be "production ready", would that mean you wouldn't want to accept patches to make it production ready? :)
> 
> Patches to make the text output better are certainly fine. We’ve just never put effort into it up until now—for a while the notes weren’t even associated with the right warnings—and we’d need to make sure we don’t optimize the textual notes at the cost of the HTML output. OTOH, the HTML output could also use some love.
> 
> Ted, Anna, do you have an opinion here?

Basically, the most comprehensive output you get for the static analyzer is the plist format (used by Xcode), followed by HTML, and finally by text. You don't get the best user experience by looking at text output. We are definitely open to patches that would improve text format, thought it will always be inferior to other formats and visualizations. If consuming plist format is an option in your use case, I'd recommend going for that instead.


> 
> 
>> Additionally, the analyzer is not expected to do sensible things without the “core" checkers enabled if you’re running any path-sensitive checks. At some point I’ll fix things so that that’s automatic, but for now please always include “core” in the control list.
>> 
>> What would be a good test case for a path sensitive check that relies on core?
>> I implemented your suggestion in r194807, but didn't find a good way to test…
> 
> Null pointer dereferences, null function calls, and use of undefined values are checked by core, as well as the fact that noreturn functions are actually noreturn. That last is fairly important to get any kind of useful results on code that uses asserts.
> 
> What I was trying to ask is: what would be a good test of a checker which is not in core that will misbehave if core is not enabled?
> 

This is one such example:
#include <stdlib.h>
int test(int *valid) {
  int *p = malloc(4);
  int x = 1;
  if (x)
    exit(0);
  else 
    free(p);  
  return 0;
}

This would report a leak if unix.Malloc checker is on but core is not on. (core tells us that the execution does not continue after a call to exit(0).)

> Cheers,
> /Manuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131115/e6a90452/attachment.html>