[cfe-commits] [PATCH] Treat "int (^x)()" as "int (^x)(void)" instead of a K&R style prototype

[Eli Friedman]

On Sun, May 31, 2009 at 11:31 AM, Chris Lattner<clattner at apple.com> wrote:
>
> On May 31, 2009, at 8:58 AM, Fariborz Jahanian wrote:
>
>> For blocks in gcc we followed the rules for function pointers in the
>> host language wrt to block pointers.
>> This change will make it more c++-ish and may break some of our
>> internal projects.
>> But it is a new feature and it is good to tighten up the rules. So it
>> is OK.
>
> While I sympathize with wanting to tighten up new features, this makes block
> pointers work differently than function pointers.  Is it really worth it?
>  What problem does this solve?

This was inspired from the following comment (and corresponding code):

/// typesAreBlockCompatible - This routine is called when comparing two
/// block types. Types must be strictly compatible here. For example,
/// C unfortunately doesn't produce an error for the following:
///
///   int (*emptyArgFunc)();
///   int (*intArgList)(int) = emptyArgFunc;
///
/// For blocks, we will produce an error for the following (similar to C++):
///
///   int (^emptyArgBlock)();
///   int (^intArgBlock)(int) = emptyArgBlock;
///
/// FIXME: When the dust settles on this integration, fold this into mergeTypes.
///

If we really want to try and treat block pointers and function
pointers as close as possible, we can do that, but in that case, we
should do it consistently.

Also, it's impossible to actually define a block without a prototype
that takes any arguments, so that removes a lot of the motivation for
K&R style declarators.

-Eli