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

[Manuel Klimek]

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/bcecdf70/attachment.html>