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

[Jordan Rose]

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?


> 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.

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