When Swift runs on wasm32-unknown-wasip1-threads in a web browser,
WebAssembly waiting instructions cannot be used on the main thread.
However, Synchronization mutex locking currently assumes it may block in
that situation, which makes contended locking fail in browser hosts when
it reaches `llvm.wasm.memory.atomic.wait32`. (you will see
`Atomics.wait cannot be called in this context`)
wasi-libc has an opt-in mode that makes futex wait on a thread to use
busywait instead of `atomic.wait32`. This change adopts the same model
by referencing the same opt-in flag.
See: WebAssembly/wasi-libc#562.
We were processing the header correctly, but remembering the wrong
offset for the DIE. This was causing missing abbrev errors because
we were then interpreting the wrong bytes.
rdar://178774635
# CMake: Add Emscripten build system configuration
Wire the `wasm32-unknown-emscripten` target through the build infrastructure. No Swift stdlib code yet.
- Product classes `EmscriptenSysroot` and `EmscriptenLLVMRuntimeLibs` (emsdk sysroot + compiler-rt builtins), `EmscriptenStdlib` (configures the stdlib + SDK overlay against the sysroot), `EmscriptenSwiftSDK` (bundles the artifacts into a Swift SDK archive).
- CLI flags `--build-emscripten-stdlib`, `--skip-test-emscripten-stdlib`, `--emscripten-path`. Default build flows are unaffected unless `--build-emscripten-stdlib` is passed.
- `utils/wasm/emscripten-run.py` runner (Node.js), alongside `utils/wasm/wasi-run.py`.
- `SwiftUtils.cmake` adds `is_wasm_sdk()` so `test/CMakeLists.txt` derives the per-SDK embedded test target instead of hardcoding WASI.
- `stdlib/public/CMakeLists.txt` and `test/CMakeLists.txt` handle the `EMSCRIPTEN` SDK but stay inert until `SWIFT_EMSCRIPTEN_SYSROOT_PATH` is set, which only happens via `--build-emscripten-stdlib`.
Wire the `wasm32-unknown-emscripten` target through the build infrastructure. No Swift stdlib code yet.
- Product classes `EmscriptenSysroot` and `EmscriptenLLVMRuntimeLibs` (emsdk sysroot + compiler-rt builtins), `EmscriptenStdlib` (configures the stdlib + SDK overlay against the sysroot), `EmscriptenSwiftSDK` (bundles the artifacts into a redistributable SDK archive).
- CLI flags `--build-emscripten-stdlib`, `--skip-test-emscripten-stdlib`, `--emscripten-path`. Default build flows are unaffected unless `--build-emscripten-stdlib` is passed.
- `utils/wasm/emscripten-run.py` runner (Node.js), alongside `utils/wasm/wasi-run.py`.
- `SwiftUtils.cmake` adds the `SWIFT_WASM_HOSTED_SDKS` registry and `sdk_has_wasm_sysroot()` so `test/CMakeLists.txt` derives the per-SDK embedded test target instead of hardcoding WASI.
- `stdlib/public/CMakeLists.txt` and `test/CMakeLists.txt` handle the `EMSCRIPTEN` SDK but stay inert until `SWIFT_EMSCRIPTEN_SYSROOT_PATH` is set, which only happens via `--build-emscripten-stdlib`.
There are still more hosted dependencies in the concurrency library +
cooperative global executor, which is causing breakage on some new C++
library implementations. Go back to hosted until we sort those out.
The former isn't really needed in Embedded, and the latter needs
standard input to make any sense. We can re-enable these once we have
clear platform requirements for them.
The functionality that depends on these functions isn't needed in
Embedded Swift. Drop it from embedded swift so we don't have these
hanging dependencies in the embedded standard library.
Implementing this function would require us to extend the metadata
format to include size information, which is heap overhead for all
callers. And we don't actually need the function for anything in
embedded, because we know the sizes of everything at construction
time.
Mark this function and those builtins that build on it as unavailable
in Embedded Swift, and #if out the code on embedded that would have
used them unnecessarily.
The optimizer can introduce calls to these functions to convert an
integer literal value into a floating point number. Provide Swift
implementations of these functions (directly ported from C++) for use
in Embedded Swift.
Later, we can drop the C++ implementations to use these everywhere.
The cooperative global executor uses <chrono> for its handling of
times. This creates a dependency on a C++11 standard library, and
doesn't actually work with freestanding implementations like we want
for Embedded Swift.
Replace this <chrono> usage with swift_sleep / swift_get_time from
the concurrency library, which already considers various
platform-specific implementations before falling back to <chrono>.
Enable -ffreestanding for the embedded Concurrency library and its
support libraries.
…rather than lazily populating the _isSet flags on access. In most cases
this should go from O(n) writes to 0, since none of them will be set
(#89651)"
This reverts commit c5f72c8f19.
This optimization pull broke the Android CI, #89708, so reverting until
we can figure out why.
Memory analysis tools have trouble identifying the metadata allocator pages. When allocating a new page, write a pointer to the previous page at the end. Combined with the existing _swift_debug_allocationPoolPointer variable, this will allow all metadata allocation pages to be identified definitively.
rdar://175515505
This builtin cannot be used inside inlinable functions without a feature
guard. It is needed for ~Escapable elements. Guarding the uses with a feature
flag will, however, be quite cumbersome. Let's hope that by the time we need ~E
elements, the oldest relevant toolchain has support for this builtin.
Fixes rdar://178659021 (condfail: error: module 'Builtin' has no member named
'borrowAt')
This makes it possible to differentiate OrNull variants from the base
attributes. For now they do the same thing as the base variant, but they
will diverge in a later commit. Clone the test structure of the base
variants to track regressions separately.
Add an environment variable that makes swift_getCanonicalSpecializedMetadata ignore noncanonical specialized metadata, for testing runtime-instantiated metadata.