This TODO has existed since the introduction of the Windows platform and
has not been addressed. The implementation at this point is well tested
in practice. Clean up the warning message and style and remove the
warning.
This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
This removes the explicit tree structure reference in the stubs to
locate the shims. Instead, it expects that the `SwiftShims` directory
will be added to the header search path.
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.
__swift_size_t on Windows is a size_t, which makes it potentially a
64-bit integer. ULONG, however, is always a 32-bit integer, and so this
cast risks shrinking the apparent size of the cbBuffer argument to
BCryptGenRandom. The effect of that will be to underfill the buffer,
leaving it full of uninitialized memory that we would treat as random.
The actual risk from this in the current implementation is basically
zero, as user code can only ever invoke this with an argument size of 8.
There's no good reason to leave this sharp edge on the API though.
On Windows the filesystem is not case sensitive and this will link just fine.
However, the Windows SDK provides the import library with the lowercase name.
Adjust the name so that the link actually succeeds on case-sensitive file
systems (like on Linux). This fixes the Windows cross-compile.
The system header depends on Windows.h but does not include it itself. This
results in base Windows types (e.g. ULONG) to be undefined. Include the header
to include the needed typedefs.
