On Jun 14, 2013, at 5:54 PM, Eli Friedman <[email protected]> wrote:
> On Fri, Jun 14, 2013 at 5:00 PM, Eli Friedman <[email protected]> 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.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits