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

[David Blaikie]

On Mon, Jan 12, 2015 at 4:07 PM, Sean Silva <chisophugis at gmail.com> wrote:

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

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/
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150112/207f3759/attachment.html>