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

Alexander Kornienko alexfh at google.com
Wed Jan 29 09:15:38 PST 2014

  > 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".

  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?


More information about the cfe-commits mailing list