Microsoft has reserved the identifier 'S' as the swift calling
convention. Decorate the symbols appropriately. This enables swift on
Windows
Details
- Reviewers
rnk
Diff Detail
- Repository
- rC Clang
Event Timeline
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.
@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.
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) {} };
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.
@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.
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. |
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 |
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. |
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. |
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. |
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.
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.