On Wed, Jan 29, 2014 at 6:15 PM, Alexander Kornienko <[email protected]>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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
