How it would be better than dealing with the appropriate data model, expressed in terms of C++? On 29 Jan 2014 20:16, "Manuel Klimek" <[email protected]> wrote:
> 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
