[cfe-dev] RFC: Flesh out the IRGen C++ ABI class

[Douglas Gregor]

On Oct 26, 2010, at 4:47 PM, John McCall wrote:

> On Oct 26, 2010, at 4:09 PM, Charles Davis wrote:
>> On 10/25/10 10:28 PM, John McCall wrote:
>>> My inclination is to say that "canonicalizing" the function type is the wrong thing to do, and that the default CC for a function in any particular context should be determined by that context.  That means that a default-CC function type is different from a specifically-cdecl function type, but I can live with that.
>> So you're saying we should get rid of getCanonicalCallConv()? Then I can
>> dispense with the AST hook, too.
>> 
>> I don't know about this. The whole point of canonicalizing the CC was
>> that cdecl function types were compatible with default-CC function
>> types. This matters when, e.g., trying to merge two compatible
>> declarations, or assigning function pointers. Are you sure you can live
>> with it now?
> 
> There's already explicit function-merging logic that deals with CCs.
> 
> The problem is that a function type with no explicit CC really is different in important ways from a function type with an explicit CC.  In particular, if I have
>  typedef void callback_t(A*);
> then this:
>  callback_t B::*cb = ...;  (b->*cb)(a);
> uses the default calling convention for instance methods, whereas this:
>  callback_t *f; f(a);
> uses the default calling convention for normal functions.
> 
> Similar, if callback_t is __attribute__((cdecl)), then instance methods declared with that typedef (which is legal!) should be called with cdecl.
> 
> The point is that function types exist independent of any particular declaring context, and the right rule is to fill in a sensible calling convention based on context when none was mandated.  If that means that we have to produce different template instantiations for __attribute__((cdecl)) functions than unadorned ones, I can live with that.


I think we have to live with the fact that we produce different template instantiations for __attribute__((cdecl)) functions than unadorned ones. I haven't looked into what GCC does, but different name-mangling for cdecl, fastcall, etc. function types makes perfect sense. 

	- Doug