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

[Manuel Klimek]

+alexfh who is going to spend time on this


On Fri, Nov 15, 2013 at 7:59 PM, Anna Zaks <ganna at apple.com> wrote:

>
> 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/20131210/1d795d38/attachment.html>