[PATCH] Add mangling for protocol-qualified ObjC types

[John McCall]

On Jun 14, 2013, at 5:54 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Fri, Jun 14, 2013 at 5:00 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> Attached is a patch to add a mangling for protocol-qualified ObjC types (like id<MyProtocol>).  The mangling is pretty straightforward:
> 
> <protocol-qualfied-type> ::= U10__protqual <protocol name>+ E <base-type>

You should embed the qualifiers as part of the <source-name> the same way that we handle address spaces;  otherwise, this doesn't really follow the vendor-extended qualifier grammar.

We're encouraged to use the source spelling of the qualifier if it has one, which is why we use 8__strong and the like, but these don't have a source spelling.  Go with objcproto or something.

So id<A,B> would be qualified as P12objcproto1A1B11objc_object, if I've got it right.

> This is necessary so we can mangle things like protocol qualified types in template parameters without causing a conflict with unqualified types (see, e.g. <rdar://problem/14074822>).
> 
> The obvious issue here is that this isn't ABI-compatible with previous clang versions.  However, the question of ABI-compatibility doesn't actually come up in common cases.  clang currently has code in Sema which prevents overloading a function based on an argument where the only difference is protocol qualification.  Taking advantage of this, this patch avoids changing the mangling for any function where protocol qualifications only show up in arguments of type ObjC interface pointer and arguments of type pointer-to-ObjC interface pointer.  Doug and I think that this is enough to avoid the worst of the ABI breakage.

Honestly, I'd rather just accept the risk of ABI breakage here.  The inability to overload based on protocol qualification doesn't seem like the sort of inherent restriction that we'd want to permanently commit to;  it seems like a minor complexity that we punted.

On the other hand, we might want to consider substituting protocol names if we start remembering these in arguments.  That would require a new type mangling.

> (This patch also changes the relevant overloading code in Sema to be a bit more consistent with what it considers an overload, to make IRGen easier to implement.)

This part seems fine, although I don't know why it matters to IR-gen. You mean the mangler?

> John, I would appreciate any comments you have.
> 
> Attaching updated version which fixes a couple bugs.

                              bool QualProtocolHack);

IgnoreArgProtocolQuals would be a better name if we keep this hack.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130617/5e730729/attachment.html>