[runtime] Remove TwoWordPair and use the Swift calling convention instead.

[troughton]

Reinstate #13299, which was reverted in #14079 due to a bug in the original PR.

Original PR message:

Historically, TwoWordPair seems to be a >4 year old hack that worked around the lack of a dedicated calling convention to interoperate with Swift. On some platforms, it packed two word-sized values into a larger integer to ensure it would be passed in registers.

Now that SwiftCC exists we don't need that hack anymore and can instead mark all functions that used TwoWordPair::Return as using the Swift calling convention.

Note that I split up TwoWordPair into different struct types. Using the templated TwoWordPair gives compile-time warnings that the functions have C-linkage but use an incomplete type that's potentially incompatible with C.

This fixes Swift functionality on 64-bit Windows; previously we would crash in an assertion on ManagedBufferPointer when trying to do anything more than a print statement since ClassExtents wasn't correctly being returned from _getSwiftClassInstanceExtents.

[troughton]

@gparker42

[troughton]

I think it's correct to use swiftcall here, but it's worth noting that this method was added since the original PR.

[gparker42]

All three of the allocBox pieces should be swiftcall: the _swift_allocBox function pointer and the functions swift_allocBox and _swift_allocBox_.

Having said that, I see that Instruments does not actually use the _swift_allocBox function pointer which is the only reason for the extra function and function pointer to exist. We can mark swift_allocBox as swiftcall and delete the other two.

[gparker42]

I'm planning to remove all of these function pointers later. For now we can just fix the existing swift_allocBox pieces in place.

[troughton]

I've removed the function pointer and simplified it to just the implementation. Unless I'm mistaken (and it's entirely possible I am), we shouldn't need to repeat the SWIFT_CC(swift) before the implementations since it's already in the header files.

[gparker42]

Or delete them now. That's good too.

[gparker42]

There is also a function pointer declaration in InstrumentsSupport.h.

[troughton]

I removed the BoxPair (*_swift_allocBox)(Metadata const *type) declaration there in the same commit.

[gparker42]

Apparently I can't read header files today. I missed that and your earlier change to swift_allocBox in HeapObject.h. Everything looks good now.

[gparker42]

@swift-ci please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - cf28ff4

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - cf28ff4

[compnerd]

Ugh, should this wait for https://reviews.llvm.org/D42768 ?

[gparker42]

What effect would D42768 have on this change?

[troughton]

I don’t think there’s much reason to wait. This was in for a few months previously and fixes the Win64 build. If someone hits the Clang assertion on Windows because of this, they can make a one-line change in Clang’s MicrosoftMangle.cpp to get past it until your Clang PR is merged.

Besides, I think Windows uses swiftcall C functions even without this PR.