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

[Manuel Klimek]

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

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