On Mon, Jan 12, 2015 at 4:07 PM, Sean Silva <[email protected]> wrote:
> > > On Mon, Jan 12, 2015 at 4:00 PM, David Blaikie <[email protected]> wrote: > >> >> >> On Mon, Jan 12, 2015 at 3:46 PM, Sean Silva <[email protected]> >> wrote: >> >>> 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. >>> >> >> Perhaps - I'm not sure if "compiled in, but designed to not add >> complexity to the main codepaths" would meet the bar of the Powers That Be >> (Richard Smith, mostly, maybe Doug, etc). >> >> Does anyone care about the size of the clang binary? (I know people care >> about the size of LLVM so as to be able to use it as a library in web >> browsers, etc) If not, it seems pretty harmless to put some AST checkers in >> that way. >> > > It might be possible to have them as a separate lib that can optionally be > linked in based on a configure-time option. > Yep, would be a possibility, if necessary/desirable. > I suspect that we may have some warnings already that could be excised > from the main codepath and put into here, so the net effect might be to > enable a slimmer clang for those wanting to reduce clang binary size. > True. It'd be interesting to get a feel for the performance of clang-tidy-esque checks, too. I wonder how much of a perf hit it would be to rephrase some existing warnings in terms of AST matching. - David > > -- Sean Silva > > >> >> >> - David >> >> >>> >>> >>> 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
