[cfe-commits] [PATCH] Constructor and Destructor mangling, along with improved Calling Convention handling for Windows.

John McCall rjmccall at apple.com
Mon Jan 24 11:43:20 PST 2011


On Jan 24, 2011, at 10:01 AM, Douglas Gregor wrote:
> The calling-convention changes are going to need a bit more discussion. The main change is this:
[snip]
> which partially separates the notion of "is this the default calling convention"? from the description of the calling convention. However, it's not a complete separation, which I find a bit awkward. I could imagine removing CC_Default entirely, then adding the "the function type was written without an explicit calling convention" bit. When the function type itself is created, we pick the calling convention based on context (?) if it's default.

It's not clear to me how this is supposed to work for typedefs or any other way we might get a function type independent from a single declaration.  Plus, as you say, this leads to weirdness with typeof/decltype.

I think CC_Default is actually the "least surprise" solution, but that we should change canonicalization so that CC_Default doesn't have any special relationship with CC_C or anything else.  We then make the "isSameCallConv" predicate be context-dependent, where the contexts I can see are:  (1) normal file-scope and static member functions, (2) blocks, (3) non-static member functions, and (4) Objective-C methods (although obviously the last doesn't come into play in the general type system).

So these types would no longer have the same canonical type, which I think is good:
  cdecl void(int)
  void(int)

What I think is a more interesting question is whether these types have the same canonical type:
  cdecl void(*)(int)
  void(*)(int)
Clearly these are logically the same type, but the problem is that (1) it's possible to detect the difference with template argument deduction and (2) throwing a pointer on something and then removing it would no longer be a semantic no-op.

So maybe the best solution is to leave them canonically distinct and introduce more 'noreturn'-like conversions, which I'm sure is what you wanted to hear. :)

John.



More information about the cfe-commits mailing list