[wasi-libc](https://github.com/WebAssembly/wasi-libc) is a libc
implementation widely used in WASI toolchains. This patch adds a new
module named WASILibc. Some extra emulation libraries are also added as
wasi_emulated_xxx.
`<xstddef>` was removed since MSVC 14.37. It isn't meant to be used by most users, but the reference will break all clients of `vcruntime`, including Swift standard library itself.
Add a couple of submodules for these modules to further modularise the
headers. This might expose additional APIs now as some of these headers
would not have been indirectly included and wind up in the wrong module.
This makes the `stdint` module implicit which repairs the ability to
build some components. In order to accomplish this, we need to
potentially break the fragile Swift build system. Due to the incorrect
handling of compilers we need some workarounds to support
cross-compilation. This removes the injected system header paths when
building on Windows to ensure that the clang resource headers are not
following the system headers which breaks the modules as the clang
resources are dependent on the system headers when running in hosted
mode.
Add the missing `std._Private.xstddef`, `std._Private.yvals`, and
`std._Private.yvals_core` modules. This repairs the use of `std.map` as
a private member variable of a type with an explicit ctor.
Specify the C++ standard required for these submodules. Although this
has no practical implications, it is useful for isolating the features
with different C++ standards.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
It shares many of the same values as OpenBSD (which both inherited from 4.4BSD),
and we wouldn't expect those to diverge due to the respective platforms'
bincompat goals.
This patch goes through and adds zippering and the swift module
dependencies to a bunch of pieces of the swift runtimes. Here's to
hoping I hit everything that needed to be hit. :D
With this patch, I'm seeing the appropriate modules under
lib/swift/maccatalyst, so things seem to be working right.
When SwiftGlibc.h was added in #32404, no cmake code was added to copy it to the
static resources. Copy it along with glibc.modulemap, which references it.
This macro was previously substituted when generating `glibc.modulemap` file during the compiler build. Now Swift detects the location of Glibc dynamically and injects `glibc.modulemap` into it using LLVM VFS. The last usage of `GLIBC_INCLUDE_PATH` was removed in `78c0540b`.
This also removes `SWIFT_SDK_${sdk}_ARCH_${arch}_LIBC_INCLUDE_DIRECTORY` which doesn't have any usages left.
This improves portability of the Swift toolchains by removing a usage of absolute path to Glibc.
The Glibc modulemap is now injected into the Glibc include path using LLVM VFS, so it can reference Glibc headers using relative paths. This already works for other Glibc headers (e.g. `assert.h`)
Add some of the x* headers to the c++ module. These are included
multiply and so we create private modules for them rather than
associate them with a different module which could cause issues
in practice due to intra-module dependencies.
`assert.h` is missing from the modulemap, which causes clang to consider `assert.h` to be a part of the first module to include it. This causes issues in SwiftCompilerSources when we try to use classes coming from LLVM headers on Linux.
