[PATCH] Allow specifying a custom PathDiagnosticConsumer for use with the static analyzer.

[Alexander Kornienko]

How it would be better than dealing with the appropriate data model,
expressed in terms of C++?
On 29 Jan 2014 20:16, "Manuel Klimek" <klimek at google.com> wrote:

> On Wed, Jan 29, 2014 at 6:15 PM, Alexander Kornienko <alexfh at google.com>wrote:
>
>>
>>   > Then again, why aren't we improving the existing data formats and the
>> tools meant to consume them? (cf.
>>   > the now-inappropriately-named CmpRuns.py)
>>   >
>>   > I'm consciously giving you a hard time because I've watched the plist
>> output leave the HTML output in the
>>   > dust. scan-build on its own is much worse at reporting errors, to the
>> point where we don't even show paths
>>   > that cross files because no one has put in the time to make that work
>> in a nice way. I don't want to see
>>   > clang-tidy get all these nice features that don't translate into the
>> plists or Xcode, and I don't want clang-tidy
>>   > to have to spend a ton of effort to get the existing features of the
>> plists and Xcode. As much as possible, I
>>   > want to have one code path.
>>
>>   I feel that we're talking about different things. I certainly support
>> your ideas of feature parity in output formats and reusing the existing
>> path diagnostic consumers. But clang-tidy is not only a tool, but also a
>> library, and its "output format" is `struct ClangTidyError`
>> (tools/extra/clang-tidy/ClangTidyDiagnosticConsumer.h).
>>
>>   We can try to extend clang DiagnosticEngine to pass additional
>> information with each diagnostic (first, checker names, then maybe
>> something else), but it fits bad in its architecture (which is mostly
>> targeted at tablegen'd diagnostic IDs).
>>
>>   Plist and HTML formatters are bad options, as we'd need to round-trip
>> information through text format, which doesn't seem to be a good idea. We
>> could reuse certain logic from other diagnostic consumers, if there are
>> reasons to do this, but I don't see how we can end up having "one code
>> path".
>>
>
> We could arguably always roundtrip via some YAML wire format...
>
>
>>
>>   If you have a good alternative idea on how we could achieve, for
>> example, what I try to do in this patch + D2620, can you outline it?
>>
>> http://llvm-reviews.chandlerc.com/D2556
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140129/26c6199f/attachment.html>