<div dir="ltr"><div style>Hello Richard, Timur,</div><div><br></div><div>I tried different approaches to this issue, but they are not elegant enough as for me.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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:</div><div>void __cdecl foo(); // CC_C is default, so drop it. Becomes equivalent to void foo().</div>
<div>void __stdcall foo(); // Set CC_X86StdCall since the previous was without CC (we dropped it).</div><div><br></div><div>And the last one is my initial approach in overload resolution.</div><div><br></div><div>I would like to have an advice which approach do we prefer?</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 20 March 2013 23:19, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Mar 19, 2013 at 10:24 AM, Alexander Zinenko <span dir="ltr"><<a href="mailto:ftynse@gmail.com" target="_blank">ftynse@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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?</div>
</blockquote><div><br></div></div><div>FunctionDecls have both a canonical type and a type as written. This transformation should only be applied to the canonical type.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>By the way, we already have such behavior if an unknown CC is automatically replaced with CC_C on some targets, like here</div><div><div>void __stdcall foo(); double x = foo;<br></div><div>cannot initialize a variable of type 'double' with an lvalue of type 'void () __attribute__((cdecl))'<br>
</div></div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 19 March 2013 00:32, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>On Fri, Mar 1, 2013 at 2:39 PM, Alexander Zinenko <span dir="ltr"><<a href="mailto:ftynse@gmail.com" target="_blank">ftynse@gmail.com</a>></span> wrote:<br>
</div></div><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Hello!<div><br></div><div>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.</div>
<div><br></div><div>The patch covers:</div><div>* pointers to free functions (__cdecl by default);</div><div>* references to free functions;</div><div>* pointers to static member functions and variadic member functions (__cdecl by default);</div>
<div>* pointers to non-static non-variadic member functions (__thiscall by default);</div><div>* simultaneous calling convention adjustment and base-to-derived implicit conversion for member functions.</div><div>
<br></div><div>The patch does not cover function templates, although the approach to this is exactly the same as for PR15291.</div><div><br></div><div>I suppose functions for determining calling convention compatibility could be moved somewhere in TargetCXXABI if needed in other places.</div>
<div><br></div><div>Please, review!</div><div>Suggestions are welcome.</div></div></blockquote><div><br></div></div></div><div>This seems rather more brute force than is required. Could you instead transform CC_Default to Context.getTargetInfo().getDefaultCallingConv(...) in the relevant places?</div>
</div>
</blockquote></div><br></div></div></div></div></div></div>
</blockquote></div></div><br>
</blockquote></div><br></div>