<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 29, 2014 at 9:57 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"><p dir="ltr">How it would be better than dealing with the appropriate data model, expressed in terms of C++?</p></blockquote>
<div>I'm not arguing in favor of it, I'm just trying to figure out what exactly Jordan might really want long-term here :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On 29 Jan 2014 20:16, "Manuel Klimek" <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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><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> > 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> > 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><div><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" target="_blank">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>
</blockquote></div>
</div></div></blockquote></div><br></div></div>