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

[Sean Silva]

On Mon, Jan 12, 2015 at 4:00 PM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> 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.
>

It might be possible to have them as a separate lib that can optionally be
linked in based on a configure-time option.

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.

-- Sean Silva


>
>
> - 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/2c63d877/attachment.html>