AST: support ObjC lifetime qualifiers in MS ABI

[compnerd]

Summary

Adjust the ObjC protocol conformance workaround to be more extensible.
Use a synthetic type for the protocol (struct Protocol). Embed this
within a reserved namespace to permit extending the extended pointer
type qualifiers similarly for ObjC lifetime qualifiers.

Introduce additional special handling for __autoreleasing, __strong,
and __weak Objective C lifetime qualifiers. We decorate these by
creating an artificial template type Autoreleasing, Strong, or
Weak in the __ObjC namespace. These are only considered in the
template type specialization and not the function parameter.

[smeenai]

pin_ptr is technically not supposed to appear as a function parameter, and having it in that position can screw up demangling. Considering __strong is the default, it's probably not a good idea to map that one to pin_ptr; whichever qualifier is least likely to appear as a function parameter (though I don't know which one that is) should map to pin_ptr. The other lifetimes seem to demangle fine wherever you place them.

Do you want to add some tests for the mangling of qualifiers on function parameters themselves? That would also demonstrate the potential demangling issue.

[rjmccall]

It's not just that functions can't be overloaded on the parameter-variable type qualifier — it's not part of the function type at all, just like making a parameter 'const int' instead of 'int' is not part of the function type. I understand that MSVC mangles some things that really shouldn't be mangled, but I would greatly prefer if you could make an exception for this.

Separately, re-using existing manglings like this seems *really* sketchy. Is this 100% necessary? There's no way to just fake something up?

[compnerd]

Hmm, the only thing that we could fake would be namespaces on the parameter types. Is that better? I'm not tied to re-using the existing mangling.

[rjmccall]

In D42614#990808, @compnerd wrote:

Hmm, the only thing that we could fake would be namespaces on the parameter types. Is that better? I'm not tied to re-using the existing mangling.

I'm just worried about re-using the existing mangling causing a problem in the long run. If you're certain that it would never be sensical to talk about e.g. a cli::pin_ptr<__strong id>, then ok.

[compnerd]

Yeah, Im afraid I cannot definitely say that will never be sensible. I think I would, in fact, prefer an alternative. I'm just not sure what is a good viable alternative, especially since we are constrained in what the grammar accepts. The desugaring of the id and Class types is the saving grace here that grants us some ability to tweak the mangling.

[compnerd]

Address comments from @rjmccall

[compnerd]

@rjmccall, I've updated the approach and no longer abuse the existing decoration styles. This uses a custom namespace with artificial types to differentiate the types. I've also ensured that the parameter types do not encode the type information.

[rjmccall]

In D42614#1001279, @compnerd wrote:

@rjmccall, I've updated the approach and no longer abuse the existing decoration styles. This uses a custom namespace with artificial types to differentiate the types. I've also ensured that the parameter types do not encode the type information.

Alright, thanks, LGTM.

[compnerd]

SVN r324701

lib/AST/MicrosoftMangle.cpp

   if (Quals.hasUnaligned() ||
       (!PointeeType.isNull() && PointeeType.getLocalQualifiers().hasUnaligned()))
     Out << 'F';
+
+  switch (Quals.getObjCLifetime()) {
+  case Qualifiers::OCL_None:
+  case Qualifiers::OCL_ExplicitNone:
+    break;
+  case Qualifiers::OCL_Autoreleasing:
+    Out << "$A";  // C++/CX Ref Parameter
+    break;
+  case Qualifiers::OCL_Strong:
+    Out << "$B";  // C++/CLI cli::pin_ptr<T>
+    break;
+  case Qualifiers::OCL_Weak:
+    Out << "$C";  // C++/CX Tracking Ref Parameter
+    break;
+  }
 }
 
 void MicrosoftCXXNameMangler::manglePointerCVQualifiers(Qualifiers Quals) {

test/CodeGenObjCXX/microsoft-abi-arc-param-order.mm

 
 // Verify that we destruct things from left to right in the MS C++ ABI: a, b, c, d.
 //
-// CHECK-LABEL: define void @"\01?test_arc_order@@YAXUA@@PAUobjc_object@@01@Z"
+// CHECK-LABEL: define void @"\01?test_arc_order@@YAXUA@@P$BAUobjc_object@@01@Z"
 // CHECK:                       (<{ %struct.A, i8*, %struct.A, i8* }>* inalloca)
-void test_arc_order(A a, id __attribute__((ns_consumed)) b , A c, id __attribute__((ns_consumed)) d) {
+void test_arc_order(A a, id __attribute__((__ns_consumed__)) b, A c, id __attribute__((__ns_consumed__)) d) {
   // CHECK: call x86_thiscallcc void @"\01??1A@@QAE@XZ"(%struct.A* %{{.*}})
   // CHECK: call void @objc_storeStrong(i8** %{{.*}}, i8* null)
   // CHECK: call x86_thiscallcc void @"\01??1A@@QAE@XZ"(%struct.A* %{{.*}})

test/CodeGenObjCXX/msabi-objc-lifetimes.mm

+// RUN: %clang_cc1 -triple thumbv7-windows-msvc -fobjc-arc -fobjc-runtime=ios-6.0 -o - -emit-llvm %s | FileCheck %s
+
+template <typename T>
+struct S {};
+
+void f(S<__unsafe_unretained id>) {}
+// CHECK-LABEL: "\01?f@@YAXU?$S@PAUobjc_object@@@@@Z"
+
+void f(S<__autoreleasing id>) {}
+// CHECK-LABEL: "\01?f@@YAXU?$S@P$AAUobjc_object@@@@@Z"
+
+void f(S<__strong id>) {}
+// CHECK-LABEL: "\01?f@@YAXU?$S@P$BAUobjc_object@@@@@Z"
+
+void f(S<__weak id>) {}
+// CHECK-LABEL: "\01?f@@YAXU?$S@P$CAUobjc_object@@@@@Z"
+