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

[Timur Iskhodzhanov]

[+Reid, just FHI]

2013/3/26 Alexander Zinenko <ftynse at gmail.com>:
> 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?
>>>
>>>
>>
>