Page MenuHomePhabricator

Support Microsoft mangling of swift calling convention methods
Needs RevisionPublic

Authored by hughbe on Mar 25 2017, 11:15 PM.



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:

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.

Diff Detail

Event Timeline

hughbe created this revision.Mar 25 2017, 11:15 PM
compnerd requested changes to this revision.Mar 26 2017, 9:21 AM

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.

This revision now requires changes to proceed.Mar 26 2017, 9:21 AM
hughbe updated this revision to Diff 93080.Mar 26 2017, 11:32 AM
hughbe edited edge metadata.

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.

jordan_rose added a subscriber: jordan_rose.
jordan_rose added a subscriber: cfe-commits.
rjmccall edited edge metadata.Jul 22 2017, 6:48 PM

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.

This revision now requires changes to proceed.Jul 22 2017, 6:48 PM

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