[+Reid, just FHI]
2013/3/26 Alexander Zinenko <[email protected]>: > 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 <[email protected]> wrote: >> >> On Tue, Mar 19, 2013 at 10:24 AM, Alexander Zinenko <[email protected]> >> 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 <[email protected]> wrote: >>>> >>>> On Fri, Mar 1, 2013 at 2:39 PM, Alexander Zinenko <[email protected]> >>>> 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? >>> >>> >> > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
