AST: support SwiftCC on MS ABI

[compnerd]

Summary

Microsoft has reserved the identifier 'S' as the swift calling
convention. Decorate the symbols appropriately. This enables swift on
Windows

[compnerd]

Use reserved namespace.

[rjmccall]

Is demangling "correctly" really a more important goal here than not spuriously failing when presented with a swiftcall function type in a non-top-level position? I don't know that there was anything wrong with the previous patch's approach to this if we're just going to punt on handling it properly because MS happens to not have an official mangling for it.

[compnerd]

Handle pointers as well

[compnerd]

@rjmccall I think both of those are concerns. I'm just putting this up so that others can grab and test it. It also coincides with the approach that we have taken elsewhere in clang using the __clang namespace for extending the decoration. What is the case that I am not considering? I think that we should try to handle this as appropriately as possible. The only case that should cause a failure is if the user explicitly uses the __Swift::__swift_cc namespace.

[smeenai]

Some cases that drop the additional namespacing entirely, which is I think what @rjmccall was pointing out:

// mangles to ?f@n@@YAXXZ
namespace n {
  void __attribute__((__swiftcall__)) f(void) {}
};

// mangles to ?f@s@@QEAAXXZ
struct __declspec(dllexport) s {
  void __attribute__((__swiftcall__)) f(void) {}
};

[compnerd]

Ah, yeah, I'm just filling in the test cases for those two cases.

[compnerd]

Handle namespaces properly

[compnerd]

Add test case for non-anonymous non-Swift::swift_cc namespace.

[rjmccall]

No, I mean things like void foo(__attribute__((swiftcall)) void (*fnptr)());.

[rnk]

In D42768#994458, @rjmccall wrote:

No, I mean things like void foo(__attribute__((swiftcall)) void (*fnptr)());.

Yeah, this was the example I was going to bring up. There's no function parameter declaration to put the NNS on.

So, here's an idea that's probably general. It's what we do for vector types and (I think?) Obj-C blocks. Whenever we need to mangle a FunctionType with swiftcc, we look at the function type and mangle it as a struct __swiftcc<T> where T is the FunctionType without the convention.

[compnerd]

Handle the non-top-level decl case

[compnerd]

@rnk thats not a bad idea. However, I had implemented it slightly differently. I mangled it as if it was a PMF: so you get __Swift::__swift_cc::* as the type.

[erichkeane]

lib/AST/MicrosoftMangle.cpp

1717

When I implemented regcall, it was brought up that this was likely a bad idea, and to just choose a letter for mangleCallingConvention. It is a really stable list as it is, and if you avoid ones in the immediate pattern, you'll be fine.

[rsmith]

lib/AST/MicrosoftMangle.cpp

1061

Do we really need both of these qualifiers? This seems redundant to me.

1717

If you can get someone at Microsoft to sign off on us using a specific letter, that seems fine. Otherwise, because we don't define the ABI, we don't get to invent extensions to it, and we should instead pick something (like this) that we can be confident won't conflict with future official mangling extensions

[erichkeane]

lib/AST/MicrosoftMangle.cpp

1717

Hmm... well, when we did it with RegCall, we didn't get them to 'sign off' so to speak, but simply alerted them about it after the fact and they promised to keep an eye on it.

[compnerd]

lib/AST/MicrosoftMangle.cpp

1061

I'd rather keep both. The __Swift is to preserve this entire area for the swift extensions. The __swift_cc is the specific feature. In the future, if we need something else, we could do __Swift::__new_feature. Alternatively, we could introduce a large number of namespaces, but, I think trying to use as little as possible is nice.

1717

This is a fairly well established technique within clang, we already use this for a large number of C types (e.g. _Complex, _Atomic, etc) which MSVC does not yet support and may at some point.

[erichkeane]

lib/AST/MicrosoftMangle.cpp

1717

Types are WAAAY different from calling conventions IMO. putting a type in a __clang namespace makes a lot of sense. Putting a function into an arbitrary namespace is way different.

[compnerd]

lib/AST/MicrosoftMangle.cpp

1717

Agreed. We could go with @rnk's suggestion of wrapping the type into a template <typename T> struct __Swift::SwiftCC<T>;.

[rsmith]

The Itanium C++ ABI specifies a convention of using the source-level syntax in the mangling of vendor extensions. This gives a fairly natural naming convention for such extensions. That would suggest that the identifier to use here is __swiftcall__, not __swift_cc / __Swift. Given that the MS ABI mangles return types even for non-template functions, one consistent place to put this marker would be on the return type. That is, mangle __attribute__((__swiftcall__)) T f(...) as if it were __swiftcall__<T> f(...), and likewise for function pointer types.

[compnerd]

address design changes

[rsmith]

Looks fine to me.

[compnerd]

Update to what Microsoft has communicated offline

[rnk]

lgtm, ship it :)

[compnerd]

SVN r324439

lib/AST/MicrosoftMangle.cpp

     }
     DC = DC->getParent();
   }
+
+  const Type *Ty = nullptr;
+
+  if (const auto *FD = dyn_cast<FunctionDecl>(ND))
+    Ty = FD->getType()->getAs<FunctionType>();
+
+  if (const auto *VD = dyn_cast<VarDecl>(ND))
+    if (VD->getType()->isPointerType())
+      Ty = VD->getType()->getPointeeType()->getAs<FunctionType>();
+
+  if (Ty)
+    if (Ty->getAs<FunctionType>()->getCallConv() == CC_Swift)
+      for (const char *NS : {"__swift_cc", "__Swift"})
+        mangleSourceName(NS);
 }
 
 void MicrosoftCXXNameMangler::mangleCXXDtorType(CXXDtorType T) {

     mangleQualifiers(Quals, /*IsMember=*/false);
   }
 
+  // We currently mangle the SwiftCC as `__Swift::__swift_cc` namespace on the
+  // decl in mangleNestedName.
+  if (CC == CC_Swift)
+    CC = CC_C;
+
   mangleCallingConvention(CC);
 
   // <return-type> ::= <type>

test/CodeGenCXX/msabi-swiftcall-cc.cpp

+// RUN: %clang_cc1 -triple i686-unknown-windows-msvc -emit-llvm %s -o - | FileCheck %s
+
+void __attribute__((__swiftcall__)) f(void) {}
+// CHECK-DAG: @"\01?f@__swift_cc@__Swift@@YAXXZ"
+
+void (__attribute__((__swiftcall__)) *p)(void);
+// CHECK-DAG: @"\01?p@__swift_cc@__Swift@@3P6AXXZA"