[cfe-commits] [patch] Function literal to bool conversion fixit notes

[David Blaikie]

On Fri, Dec 9, 2011 at 1:40 PM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Dec 9, 2011, at 12:15 AM, David Blaikie wrote:
>
>
>
> On Thu, Dec 8, 2011 at 8:01 PM, Matt Beaumont-Gay <matthewbg at google.com>wrote:
>
>> On Thu, Dec 8, 2011 at 19:43, David Blaikie <dblaikie at gmail.com> wrote:
>> > Just adding some finishing touches to Lang's recent excursion into the
>> front
>> > end by adding notes to describe how to suppress (and in simple cases,
>> fix)
>> > the warning
>> >
>> > /tmp/webcompile/_7230_0.cc:3:10: warning: address of function 'f1' will
>> > always evaluate to 'true' [-Wbool-conversions]
>> >   return f1;
>> >          ^~
>> > /tmp/webcompile/_7230_0.cc:3:10: note: prefix with the address-of
>> operator
>> > to silence this warning
>> >   return f1;
>> >          ^
>> >          &
>> > /tmp/webcompile/_7230_0.cc:3:10: note: suffix with parentheses to turn
>> this
>> > into a function call
>> >   return f1;
>> >          ^
>> >            ()
>> >
>> > The latter note is only included if the function has a bool return and
>> no
>> > arguments (I couldn't figure out how to account for default or variadic
>> > arguments - suggestions welcome. Also for bool conversion) so this is
>> fairly
>> > simple.
>>
>> You might be interested in Sema::isExprCallable and
>> Sema::tryToRecoverWithCall.
>>
>
> Hey - thanks for the tip. That is really handy. It doesn't /seem/ to be
> doing much better than my first attempt (it doesn't seem to ever trigger
> the interesting case that uses FunctionDecl::getMinRequiredArguments - I'm
> still poking around with that. Perhaps this function can be generally
> improved for all callers) - and, curiously, the simple test cases I've
> tried ("struct foo { void bar(); }; int main() { foo f; f.bar; }") seem to
> have interesting behavior as you change whether the function is overloaded,
> callable, etc (it seems that the diagnostic caret location changes from f
> to bar, depending on that, among other things))
>
>
> This function could/should be improved, especially to make it cope with
> member functions better.
>
>

I'll have a play around with it separately & see what I can come up with.


>
>
> [updated with a version using isExprCallable - and also keeping the CC
> location in the warning that I'd previously removed
>
>
> LGTM!
>
>

Thanks Doug! Committed as r146280


>
>
> (but fixing its location by giving BinaryOperator a getExprLoc that
> provides the operator location which makes things read better - is that
> OK?)]
>
>
> Yes, that's a useful improvement.
>
>

Great.

Thanks again,
- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111209/8be47dc7/attachment.html>