The new headers for LWG-3268 in the new VC release broke the
modularisation of `std.atomic`. Add the dependent private module to
ensure that we correctly modularise the dependency and allow
`std.atomic` to be built again.
Added the _modules workaround to make the compiler pull in the correct
module when someone does `import stdc_assert` (for instance).
Fix various niggles.
rdar://123503615
We need to declare separate top-level modules for every header in
the musl C library. Note that our set-up here does require some
tweaks to musl itself (specifically, the `alltypes.h` header needs
some fairly serious massaging to make it module compatible; in
particular, we need to pull out every type declaration into its
own separate modularized header in `bits/types`).
Also update `Platform.swift` a little for more musl support.
rdar://123503615
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
This is needed to support Apple internal configurations that would fail
consuming such binary swiftmodule (but work as expected when rebuilding
from the swiftinterface).
Addresses rdar://124390643
[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.
