[PATCH] PR13457 (part 1) explicit/implicit calling conventions compatibility in overloads

[Alexander Zinenko]

This is possible when acting on FunctionDecl, but it can affect diagnostics
reporting in the following way: when outputting FunctionType with
non-default CC, diagnostics engine assumes CC was specified explicitly via
__attribute__ syntax.  I am not sure this is a desired behavior.  It would
be better if there was a way to work around this, does it exist?

By the way, we already have such behavior if an unknown CC is automatically
replaced with CC_C on some targets, like here
void __stdcall foo(); double x = foo;
cannot initialize a variable of type 'double' with an lvalue of type 'void
() __attribute__((cdecl))'

On 19 March 2013 00:32, Richard Smith <richard at metafoo.co.uk> wrote:

> On Fri, Mar 1, 2013 at 2:39 PM, Alexander Zinenko <ftynse at gmail.com>wrote:
>
>> Hello!
>>
>> This patch addresses the compatibility issue between explicitly specified
>> default calling conventions and implicit ones in overload resolution.  As
>> of now, such implicit conversions are only known in Microsoft ABI.  The
>> corresponding CodeGen already knows about these implicit defaults, so the
>> conversion kind could be just NoOp.
>>
>> The patch covers:
>> * pointers to free functions (__cdecl by default);
>> * references to free functions;
>> * pointers to static member functions and variadic member functions
>> (__cdecl by default);
>> * pointers to non-static non-variadic member functions (__thiscall by
>> default);
>> * simultaneous calling convention adjustment and base-to-derived implicit
>> conversion for member functions.
>>
>> The patch does not cover function templates, although the approach to
>> this is exactly the same as for PR15291.
>>
>> I suppose functions for determining calling convention compatibility
>> could be moved somewhere in TargetCXXABI if needed in other places.
>>
>> Please, review!
>> Suggestions are welcome.
>>
>
> This seems rather more brute force than is required. Could you instead
> transform CC_Default to Context.getTargetInfo().getDefaultCallingConv(...)
> in the relevant places?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130319/e5c231fa/attachment.html>