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

[Alexander Zinenko]

Hello Richard, Timur,

I tried different approaches to this issue, but they are not elegant enough
as for me.

The first is to replace CC_Default with explicit default CC in
declarations.  It requires changing function, typedef, variable and
parameter declarations to address our problem.  But this approach results
in over 20 test failures due to diagnostics change (adds extra
__attribute__ to function type).  Although attribute printing is not
perfect now since it prints __attribute__((cdecl)) instead of __cdecl,
adding extra attributes in the output may be unwanted.

Another one is to try changing only the canonical type.  Function canonical
types are handled in ASTContext::getFunctionType and we already have a
notion of canonical calling convention (for MRTD).  But MS ABI has
different default calling conventions for instance methods and everything
else.  FunctionType does not differentiate between method types and free
function types as well as has no information about storage classes.  We can
introduce extra arguments with default values to getFunctionType, but it
might clutter the code and doesn't look like a good idea.

The third one is the inverse to the first: change explicit default CCs to
CC_Default.  This doesn't work because it breaks declaration merge:
void __cdecl foo(); // CC_C is default, so drop it. Becomes equivalent to
void foo().
void __stdcall foo(); // Set CC_X86StdCall since the previous was without
CC (we dropped it).

And the last one is my initial approach in overload resolution.

I would like to have an advice which approach do we prefer?



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

> On Tue, Mar 19, 2013 at 10:24 AM, Alexander Zinenko <ftynse at gmail.com>wrote:
>
>> 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?
>>
>
> FunctionDecls have both a canonical type and a type as written. This
> transformation should only be applied to the canonical type.
>
>
>> 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/20130326/325dc60b/attachment.html>