<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 29, 2014 at 6:15 PM, Alexander Kornienko <span dir="ltr"><<a href="mailto:alexfh@google.com" target="_blank">alexfh@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
  > Then again, why aren't we improving the existing data formats and the tools meant to consume them? (cf.<br>
  > the now-inappropriately-named CmpRuns.py)<br>
  ><br>
  > I'm consciously giving you a hard time because I've watched the plist output leave the HTML output in the<br>
</div>  > dust. scan-build on its own is much worse at reporting errors, to the point where we don't even show paths<br>
<div class="im">  > 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<br>
  > clang-tidy get all these nice features that don't translate into the plists or Xcode, and I don't want clang-tidy<br>
</div>  > to have to spend a ton of effort to get the existing features of the plists and Xcode. As much as possible, I<br>
<div class="im">  > want to have one code path.<br>
<br>
</div>  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).<br>

<br>
  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).<br>

<br>
  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".<br>
</blockquote><div><br></div><div>We could arguably always roundtrip via some YAML wire format...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  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?<br>
<div class="HOEnZb"><div class="h5"><br>
<a href="http://llvm-reviews.chandlerc.com/D2556" target="_blank">http://llvm-reviews.chandlerc.com/D2556</a><br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br></div></div>