On Wed, Jan 29, 2014 at 9:57 PM, Alexander Kornienko <[email protected]>wrote:
> How it would be better than dealing with the appropriate data model, > expressed in terms of C++? > I'm not arguing in favor of it, I'm just trying to figure out what exactly Jordan might really want long-term here :) > 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
