Support Microsoft mangling of swift calling convention methods

[hughbe]

Summary

The following code snippet crashes with clang-cl on Windows:

__attribute__((swiftcall)) void (*a)();

This is because we don't handle the swift calling convention on Windows in MicrosoftMangle.cpp.

This means that the Swift runtime can't currently be built on Windows, as the Swift runtime must be built with Clang (i.e. MSVC is not supported).

There are a couple of bugs tracking this:
http://bugs.llvm.org/show_bug.cgi?id=32000
https://bugs.swift.org/browse/SR-4302

I'm not sure the correct way to mangle the Swift calling convention. Itanium mangling uses "swiftcall", but I went with "S" in MicrosoftMangle, because it's a single character like the other calling convention mangling. Let me know if you have other suggestions for names, and I'd be happy to change this.

[compnerd]

I've sent an email to Microsoft to add this to their scheme. In the mean time, if you want to support this, we should namespace the symbol to __swift::swift_cc:: instead of the usual mangling. That would be compatible with their tools and allow us to use the custom calling convention.

[compnerd]

I think you misunderstood what I meant. I meant that you should change the mangling scheme to put the symbol into a C++ __Swift::swift_cc namespace since that is reserved. That would mean that this enumeration would not be touched at all.

[rjmccall]

You can't just change the top-level mangling of the symbol because this is used as part of the function type mangling, and those can appear at more-or-less arbitrary positions.

I cannot possibly imagine Microsoft actually officially adding mangling support for every extension we support in Clang. The closest you can reasonably expect is that they will add an official "vendor-extended" mangling. Until then, picking an arbitrary string and acknowledging that it is not stable and will not correctly demangle is a reasonable thing to do.

The llvm_unreachable in this function is not an appropriate use of llvm_unreachable, by the way, unless there's something in the frontend that actually prevents creating such things on MS targets. The uses of unreachable in ItaniumMangle are (according to our beliefs, anyway) *actually* impossible to reach, like an Objective-C selector being mangled as part of an unresolved-name. A more acceptable approach when the mangling does not implement a case is to do something like what ItaniumMangle does on unsupported expression nodes: emit a (bad) diagnostic and continue.

[compnerd]

D42768 adds the __swift_cc in the right location and demangles correctly with undname as well.

lib/AST/MicrosoftMangle.cpp

   //                      ::= J # __export __fastcall
   //                      ::= Q # __vectorcall
   //                      ::= w # __regcall
+  //                      ::= __swift::swift_cc:: # __swiftcall (will change when Microsoft adds this to their scheme)
   // The 'export' calling conventions are from a bygone era
   // (*cough*Win16*cough*) when functions were declared for export with
   // that keyword. (It didn't actually export them, it just made them so

     case CC_X86FastCall: Out << 'I'; break;
     case CC_X86VectorCall: Out << 'Q'; break;
     case CC_X86RegCall: Out << 'w'; break;
+    case CC_Swift: Out << "__swift::swift_cc::"; break;
   }
 }
 void MicrosoftCXXNameMangler::mangleCallingConvention(const FunctionType *T) {