[cfe-commits] Fix PR13434 - mangling of templates with function pointers as arguments

[John McCall]

On Jul 26, 2012, at 7:47 AM, Timur Iskhodzhanov wrote:
> On Thu, Jul 26, 2012 at 5:59 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote:
>> I've started with a small r160783 that ...
>> 
>> On Mon, Jul 23, 2012 at 9:37 PM, John McCall <rjmccall at apple.com> wrote:
>>> It would be good to at least come up with a reasonable-seeming
>>> mangling for them.  Basically, please make sure they're mangled
>>> just like pointers to functions, but different in some obvious way.
>> ... adds an zeta/eta comparison between function pointer and block mangling ...
> My current problem is that I don't quite understand what a block is.

int(^)(float) is a lot like std::function<int(float)>.  In source code, you can copy it
around and call it exactly like a function;  meanwhile, how you got it — and the
variables it captures — are erased from the type.

> Given the current structure of MicrosoftMangle and ItaniumMangle, the
> following mangling makes some sense:
> 
> void zeta(int (*)(int, int)) {}
> // CHECK: @"\01?zeta@@YAXP6AHHH at Z@Z"
> void eta(int (^)(int, int)) {}
> // CHECK: @"\01?eta@@YAXP_E$$A6AHHH at Z@Z"
> // WAS:    @"\01?eta@@YAXP_EAHHH at Z@Z"
> 
> the interesting part goes after "YAX".
> "P" currently means "pointer or member pointer or block pointer"
> 
> zeta:
> "6" means "function pointer"
> After appending "6" we call ``mangleType(FT, NULL, false, false);``
> instead of ``mangle(FunctionProto, ...)``
> - why?
> 
> eta:
> "_E" means "block pointer"
> After appending "_E" we call ``mangle(FunctionProto, ...)``
> - why?
> 
> Is it true that BlockPointerType::getPointeeType is always a FunctionProto?

It's always a FunctionType.  In C++, that implies it's always a FunctionProtoType.
It could be a typedef of a function type, but if you're working with canonical
types then you don't need to worry about that.

As long as "P_E" at the start of a type cannot possibly conflict with any
existing type mangling, I think that's fine.  The approach we took in
Itanium was to start it with a different letter entirely, but that requires
a bit more care to ensure it doesn't collide with any other manglings.

I'll look at your patch later.

John.