Semantic analysis for the swiftcall calling convention.

I've tried to keep the infrastructure behind parameter ABI
treatments fairly general.

llvm-svn: 262587

1 files changed, 16 insertions, 1 deletions

diff --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index 71c94104ccc..5e079960ae1 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -2167,6 +2167,9 @@ StringRef CXXNameMangler::getCallingConvQualifierName(CallingConv CC) {
   case CC_SpirKernel:
     // FIXME: we should be mangling all of the above.
     return "";
+
+  case CC_Swift:
+    return "swiftcall";
   }
   llvm_unreachable("bad calling convention");
 }
@@ -2195,8 +2198,20 @@ CXXNameMangler::mangleExtParameterInfo(FunctionProtoType::ExtParameterInfo PI) {
   // Note that these are *not* substitution candidates.  Demanglers might
   // have trouble with this if the parameter type is fully substituted.
 
+  switch (PI.getABI()) {
+  case ParameterABI::Ordinary:
+    break;
+
+  // All of these start with "swift", so they come before "ns_consumed".
+  case ParameterABI::SwiftContext:
+  case ParameterABI::SwiftErrorResult:
+  case ParameterABI::SwiftIndirectResult:
+    mangleVendorQualifier(getParameterABISpelling(PI.getABI()));
+    break;
+  }
+
   if (PI.isConsumed())
-    Out << "U11ns_consumed";
+    mangleVendorQualifier("ns_consumed");
 }
 
 // <type>          ::= <function-type>