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

[Manuel Klimek]

On Wed, Jan 29, 2014 at 9:57 PM, Alexander Kornienko <alexfh at google.com>wrote:

> How it would be better than dealing with the appropriate data model,
> expressed in terms of C++?
>
I'm not arguing in favor of it, I'm just trying to figure out what exactly
Jordan might really want long-term here :)


> 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/20140130/974ad948/attachment.html>