**Explanation**: Cherry-pick of #83792, merged as 450cb14597
WASILibc wasn't built for the embedded stdlib in `stdlib/public/Platform/CMakeLists.txt`. New `copy_wasilibc_modulemap_embedded_resource` and `embedded-stdlib-platform-${triple}` targets are added, the latter for `wasm32-unknown-wasip1` only for now. Also added a `wasilibc_functions.swift` test to verify the result.
**Scope**: limited to Embedded Swift for Wasm;
**Risk**: low due to limited scope;
**Testing**: added new lit test to the existing Embedded Swift test suite;
**Issue**: rdar://157467412
**Reviewer**: @bnbarham
We are seeing strange crashes during embedded stdlib build stage on Ubuntu 24.04. These crashes only seem to occur when we dispatch many stdlib emit-module tasks at the same time. While we root-cause it, this change attempts to slow down the process to only two Embedded StdLib tasks at-a-time.
Workaround for rdar://137674862
This patch adds an apinotes file for SwiftWASILibc clang module to mark
`errno` macro hidden from Swift code. This resolves ambiguity between
the C macro definition and the Swift wrapper in WASILibc overlay module.
This change installs the apinotes file to the resource directories for
both lib/swift/apinotes and lib/swift_static/apinotes.
This apinote file needs to be accessible in the locally built Android SDK as it's being built with build.ps1, so that swift-foundation can be built with that file present. This change ensures that the file is copied over into the local build directory for that Android SDK, in addition to being included in the installed component
This change also places the component into lib/swift/apinotes, as that's where the clang importer already looks for API notes
Introduce the first APINotes injection for the Android platform. This
follows the VCRuntime pattern of permitting the SDK to provide API Notes
that augment the system SDK. This adds a workaround for incorrect
nullability on the `fts_open` function in bionic. The system library
itself is fixed at:
https://android-review.googlesource.com/c/platform/bionic/+/3151616
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 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.
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.
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 migrates OpenBSD to use the single-header Glibc modulemap proposed
and implemented in #32404, and necessitates introducing some missing
headers for building Foundation added in #38341.
Additionally, incorporate nullability annotations in SwiftShims per
* add an option to add freestanding to the Darwin platform, so that
to get expected compile behaviours (e.g. setting the install name)
* rework testing configuration to relax assumptions about freestanding
* add a preset to test such configuration (at least for PR testing)
Addresses rdar://85465396
Unfortunately using the convenient "bootstrapping0-all", etc. custom targets does not work.
For some reason it does not cause a dependent file (like libswift's SIL.o) being rebuilt when a depenency (like swift-frontend from the previous bootstrapping stage) changes.
Instead we have to list al library- and executable-targets explicitly.
swiftDarwin and swiftOnoneSupport didn't depend on building the Swift core library.
This was a subtle bug, because the compiler just picked up the module from the SDK instead of the (still building) Swift module.
It only resulted in compiler errors if the SDK swiftinterface was too new to be parsable by the compiler.
* fix a typo which prevented linking the right bootstrapping libs
* build swiftDarwin for bootstrapping
* disable COW checks if built with bootstrapping-with-hostlibs
* Fix two issues with the SwiftGlibc module map.
The issues are:
- Today, some submodules in `SwiftGlibc` fail to provide definitions that
they should contain. As a consequence, Swift fails to import some code
that compiles correctly with standalone Clang. As just one example,
including `signal.h` should make the type `pid_t` available, but it
currently does not.
- `SwiftGlibc` is not compatible with the libc++ module map. Trying to
include libc++ headers in a C++ module imported into Swift results in an
error message about cyclic dependencies.
This change fixes both of these issues by making it so that `SwiftGlibc`
no actually longer defines a module map for the glibc headers but merely makes
all of the symbols from those headers available in a module that can be
imported into Swift. C / Objective-C / C++ code, on the other hand, will now
include the glibc headers texually.
For more context on the two issues and this fix, see this forum
discussion:
https://forums.swift.org/t/problems-with-swiftglibc-and-proposed-fix/37594
This change only modifies `glibc.modulemap.gyb` for the time being but
leaves `bionic.modulemap.gyb` and `libc-openbsd.modulemap.gyb` unchanged. The
intent is to fix these in the same way, but it will be easier to do this
in separate PRs that can be tested individually.
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
Co-authored-by: Marcel Hlopko <hlopko@google.com>
This replaces swiftMSVCRT with swiftCRT. The big difference here is
that the `visualc` module is no longer imported nor exported. The
`visualc` module remains in use for a singular test wrt availability,
but this should effectively remove the need for the `visualc` module.
The difference between the MSVCRT and ucrt module was not well
understood by most. MSVCRT provided ucrt AND visualc, combining pieces
of the old MSVCRT and the newer ucrt. The ucrt module is what you
really wanted most of the time, however, would need to use MSVCRT for
the convenience aliases for type-generic math and the deprecated math
constants.
Unfortunately, we cannot shadow the `ucrt` module and create a Swift SDK
overlay for ucrt as that seems to result in circular dependencies when
processing the `_Concurrency` module.
Although this makes using the C library easier for most people, it has a
more important subtle change: it cleaves the dependency on visualc.
This means that this enables use of Swift without Visual Studio for the
singular purpose of providing 3 header files. Additionally, it removes
the need for the installation of 2 of the 4 support files. This greatly
simplifies the deployment process on Windows.
- deduplicate the logic to compute the resource folder
- install headers and module files in shared and static resource folders
- forward -static flag when calling swiftc with -print-target-info
Commit for CMake and build scripts to recognize OpenBSD. To keep this
commit relatively short, this just deals with the rather simple and
uncontroversial changes to the build system.
Note that OpenBSD calls "x86_64" as "amd64", Since the Swift stdlib will
be put in a subdirectory named after ARCH, to ensure the standard
library is properly found later, we use the native architecture name for
OpenBSD in the build system rather than trying to deal with the
difference the other way around.
