On Jan 13, 2014, at 10:48 , Alexander Kornienko <[email protected]> wrote:
>
> On Tue, Dec 10, 2013 at 12:29 PM, Manuel Klimek <[email protected]> wrote:
> +alexfh who is going to spend time on this
>
> On Fri, Nov 15, 2013 at 7:59 PM, Anna Zaks <[email protected]> wrote:
>
> On Nov 15, 2013, at 9:28 AM, Manuel Klimek <[email protected]> wrote:
>
>> On Fri, Nov 15, 2013 at 6:25 PM, Jordan Rose <[email protected]> wrote:
>>
>> On Nov 15, 2013, at 3:24 , Manuel Klimek <[email protected]> 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.
>
> It seems that consuming either plist or HTML format is not a good option for
> us. I'd prefer to implement a custom PathDiagnosticConsumer, so that we have
> raw data in a form easily usable from the code (unlike plist/HTML in a file).
> Analyzer currently doesn't provide an interface to pass a custom
> PathDiagnosticConsumer, but I can implement this, if you have no objections.
> My idea was to make AnalysisConsumer, that is returned from
> clang::ento::CreateAnalysisConsumer(...), implement a new public interface,
> that provides a way to add PathConsumers.
I...guess this could be okay. What we'd like to avoid is Yet Another
Serialization Format—if you're going to be dealing with the output as data,
we'd much prefer you just augment the plist format and use and improve the APIs
in utils/analyzer/CmpRuns.py (a bit of a misnomer). But another consumer for
immediate processing seems fair...so, what are you going to do with your new
PathDiagnosticConsumer?
>
> There's one more thing, that is not directly supported by the current
> diagnostic system in the Static Analyzer: in clang-tidy we'd like to know the
> name of the checker producing each diagnostic message. PathDiagnostic has
> BugType and Category fields, which are both arbitrary human-readable strings,
> but we need to know the exact name of the checker in the form that can be
> used in the CheckersControlList option to enable/disable the specific
> checker. I have a sketch of a patch, that does this. The idea of the patch is
> to add a CheckerName field to the CheckerBase class, and set it in the
> CheckerManager::registerChecker() method, which will get them from the
> CheckerRegistry class through register.*Checker() functions. Before I polish
> the patch and sending for actual review, I wanted to check with you, if there
> are any concerns regarding this.
We have deliberately resisted this, because there are two different names
associated with checkers, and it's not the name of the class that matters. The
class called MallocChecker, for example, implements unix.Malloc,
unix.MismatchedDeallocator, alpha.unix.MallocWithAnnotations,
cplusplus.NewDelete, and alpha.cplusplus.NewDeleteLeaks. If we want to start
including those names in output, it has to be on a per-diagnostic basis...and
the strings, at least, should be generated nicely from TableGen, so that we're
not dealing with raw strings.
I'd have to check with Ted but exposing just the name of the user-visible
checker setting seems like a reasonable thing to do.
Jordan
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
