Most SwiftShims were put in the swift namespace in C++ mode which broke certain things when importing them in a swift file in C++ mode. This was OK when they were only imported as part of the swift runtime but, now they are used in C++ mode both in the swift runtime and when C++ interop is enabled.
This broke when C++ interop was enabled because the `Swift` module contains references to symbols in the SwiftShims headers which are built without C++ interop enabled (no "swift" namespace). But, when C++ interop is enabled, the SwiftShims headers would put everything in the swift namespace meaning the symbols couldn't be found in the global namespace. Then, the compiler would error when trying to deserialize the Swift module.
The SDK directory is now confusing as the Windows target also has a SDK
overlay. In order to make this more uniform, move the SDK directory to
Darwin which covers the fact that this covers the XNU family of OSes.
The Windows directory contains the SDK overlay for the Windows target.
Adjust the block type to use `intptr_t` which is a register-wide integral type.
This allows the same declaration to be portable across LP64 and LLP64
environents.
Otherwise, we return in the autorelease pool and this can keep the block
alive longer than a surrounding withoutActuallyEscaping expression
causing verification failures.
rdar://45226617
SR-8955
dispatch_source_create is marked up as non-null but can actually return
null in programming error issues. In order to maintain the nullabilty
contract, these issues will now cause the overlay to assert and crash
rather than return a null pointer out of a non-null call.
Resolves: <rdar://problem/39937177>
We still have a bunch of redeclarations of Dispatch functions to avoid
the automatic bridging of dispatch_data_t and dispatch_block_t, but
mostly this is a vast reduction in complexity (and increase in safety).
