[PATCH] clang-tidy: Add initial check for "Don't use else after return".

[David Blaikie]

On Mon, Jan 12, 2015 at 3:46 PM, Sean Silva <chisophugis at gmail.com> 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.

- David


>
>
> http://reviews.llvm.org/D6927
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150112/4b55afd2/attachment.html>