[runtime] Always use SwiftCC

[troughton]

Once #13299 is merged, it will silently cause issues on some platforms if the Swift calling convention is not available.

Therefore, since every platform that Swift supports also supports the Swift calling convention, we should always use the Swift calling convention, as per discussion at #13299 (comment).

To do this, I've split some of the runtime Config.h header (which was being included by some sources outside of the stdlib/runtime) out into a newPublicConfig.h header, which can safely be included in non-runtime code whether or not the host compiler supports swiftcall.

I've added checks within the internal Config.h header that the compiler in use for the runtime supports swiftcall. I've also removed any UseSwiftCC checks as they're now redundant.

[troughton]

@gparker42 How does this look? Whichever of this and #13299 is merged second will need to be rebased, but that shouldn't be a major task.

[gparker42]

Do we gain much from the Config.h / PublicConfig.h split? We might be better off leaving Config.h as-is and adding the swiftcall enforcement to a non-header file.

[gparker42]

Either way let's do the other change first.

[troughton]

That's probably true, actually. I'm not sure which file it'd fit into, but that'd be easy to do and shrink this PR pretty significantly. If we wanted to move it into another header file HeapObject.h looks like it's runtime only and is the reason for the check, so maybe that would be a candidate? I guess equally an argument could be made for HeapObject.cpp.

[troughton]

I've shifted the check into HeapObject.cpp and reverted the split of Config.h. This should be a much simpler change now.

[gparker42]

Yes, I like this way better.

Thomas, can you run this test locally: change #if __has_attribute(swiftcall) to #if 0 in Config.h and rebuild everything. I want to verify that we currently have no incorrect usage that would break a non-swiftcall compiler.

[gparker42]

@swift-ci please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 35846d490cd3b3be0193d30a7a0e57b97fcc504a

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 35846d490cd3b3be0193d30a7a0e57b97fcc504a

[troughton]

That's a little tricky – we need the Config.h header to be correct for the runtime, since we're assuming that swiftcall is always available there. What I've done instead for now is wrapped the #if __has_attribute(swiftcall) in a #ifndef NO_SWIFTCALL and defined #NO_SWIFTCALL for each source outside of the runtime/stdlib that includes Runtime/Config.h. That check works without issue.

I've also started up a gcc-based build on the Ubuntu image, but that might take a few hours to complete. I'll report back once that's done.

[gparker42]

Good, that should cover it.

[troughton]

Looks like I missed something: while the SWIFT_CC_ macros aren't used outside the runtime, they are used in other runtime headers (e.g. Metadata.h) that are pulled in from outside the runtime. Hopefully things will eventually get properly untangled, but in the meantime I've added back the#else block to the define to fix that.

That's the same error that the Linux test caught: it's using a version of Clang that doesn't have swiftcall (I think 3.8 is the default). I've run a local compile on that version of Clang which worked fine with the new commit. My #NO_SWIFTCALL trick didn't catch it as I wasn't defining it for the cases when the Config.h header was transitively pulled in.

As an aside, compiling Swift on GCC is surprisingly difficult: MSVC support has been special-cased in a few places but the code generally assumes Clang or MSVC. I'm not sure how worthwhile maintaining that support will be in the future, but that's a different issue.

[gparker42]

@swift-ci please test