In http://reviews.llvm.org/D6927#107453, @dblaikie wrote:
> Not your problem, but I'm wondering: If/when/how we'll be able to integrate > clang-tidy checks into the compile step for developers. This warning and many > others in clang-tidy ought to be cheap enough to run at compile time and as > hard errors just like many real clang warnings (the only reason they're not > is that they're stylistic in nature and so don't meet that bar for the > compiler warnings - not because they aren't cheap, low false positive, etc). > It'd be nice not to have these as asynchronous results but as errors during > the build. Maybe there's scope for a way to add warnings/errors which are run as a separate AST consumer, rather than integrated into the parsing/lexing code path. That way, you don't pay for them if you don't use them (also you don't pay for them in added complexity within the parsing/lexing code). I think most AST-based clang-tidy checks would fit that model. We also have a warning we added internally that would be very nice to cleanly segregate out of the main code path like that. http://reviews.llvm.org/D6927 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
