64-bit Windows defines both _WIN64 and _WIN32, so the logic here would
always end up defining 32-bit C types for Swift's `Int` and `UInt`.
Fix the ordering to check for 64-bit first, then 32-bit second.
Note that the SwiftShims version of this code has always been wrong,
but it's completely benign because SwiftShims is only used in the
Swift runtime itself, which is built with Clang (on all platforms),
and doesn't need to go through this code path. Still, we fix it in both
places, so we don't get a nasty surprise if the SwiftShims version of
the header later gets included in a non-Clang C++ compiler.
The C type tha corresponds to Swift's pointer-sized `Int` and `UInt`
types varies from one platform to the next. The canonical C types are
`ptrdiff_t` and `size_t`, but we're in the depths of the compiler we
can't include the C library headers that provide them because they
introduce cyclic module dependencies. Sigh.
SwiftShims has some logic to compute these types. However, SwiftShims
is part of the Swift runtime, not the compiler, so those headers
cannot be included here. So, we clone the logic and simplify it
somewhat for our use case.
This fixes truncation issues on Windows, where the uses of
`unsigned long` and `long` for Swift(U)Int are incorrect.
C stdlib headers are part of "Darwin"/"Glibc" clang module.
If a Swift file imports a bridging headers and that has '#include'
C stdlib headers, Swift compiler implicitly imports "Darwin"/"Glibc"
overlay modules. That violates dependency layering. I.e. Compiler
depends on Darwin overlay, Darwin overlay is created by the compiler.
rdar://107957117
