[PATCH] Emit diagnostic on illegal calling convention

[Alexander Zinenko]

On 17 April 2013 21:41, John McCall <rjmccall at apple.com> wrote:
>
> Okay, so we don't actually move the CC attribute effectively.  Good to know.
>
>
> You wouldn't normally write it, but this is totally legal:
>   typedef ((((__stdcall (*((ptr)))))()));
>

Thanks, added as an extra test case.

>
> Yeah, this is a consequence of my misunderstanding about moving the
> attribute.
>
> Okay, so here's what you should do:
>   - If we're on a function declarator chunk right now, walk "inwards".
>   - Keep walking inwards past an arbitrary number of parens.
>   - If you run out of declarator chunks, this is a function declarator, and you should check the declaring context, whether this is a friend, whether it's static, etc.
>   - Otherwise, if it's a member-pointer chunk, this is an instance method context.
>   - Otherwise, it's a "normal" function pointer context.
>

Done.

>
> Yes, I know.  What I mean is that we can get away with just checking for explicit storage-class specifiers, friend specifiers, etc. because, if this is an out-of-line method definition, we won't be able to accept an illegal CC anyway because it won't match the CC from the original declaration.
>

Sure. And ignore the specifiers if this is not a function declaration,
but something else, for example function pointer variable which is
declared static.

>> On the other hand, friend declarations will not be handled correctly
>> this way since we can no longer differentiate between friend free
>> functions and friend methods from other classes. And we have no
>> diagnostic if friend declaration uses different CC than original
>> declaration.
>
> Really?  That's a bug.

Actually not. Sorry for the noise, this patch set the attribute as
invalid so that CC mismatch diagnostic ignored it.

>
> John.

--
Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: callconv.patch
Type: application/octet-stream
Size: 16538 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130418/7f103a06/attachment.obj>