This patch allows running executable tests with WasmKit. If WasmKit is
not built, fall back to running only non-executable tests. Also add
stdlib and Concurrency executable tests to run.
This patch adds a new product, WasmKit, which is a Wasm runtime that is
going to be used to run executable tests targeting Wasm. Note that the
product is not shipped as a part of the toolchain, but is used only for
testing purposes.
This library uses GenericMetadataBuilder with a ReaderWriter that can read data and resolve pointers from MachO files, and emit a JSON representation of a dylib containing the built metadata.
We use LLVM's binary file readers to parse the MachO files and resolve fixups so we can follow pointers. This code is somewhat MachO specific, but could be generalized to other formats that LLVM supports.
rdar://116592577
This patch introduces `--enable-experimental-noncopyable-generics` for
the build script. It replaces
`--swift-stdlib-experimental-noncopyable-generics`
The old build option only enables the feature when building the
stdlib, but if we've built the stdlib with NoncopyableGenerics, the
compiler should be hardwired to have that feature enabled, too.
This patch also introduces the `noncopyable_generics` lit parameter, so
that tests assuming the system was built with the feature can live
in-tree and be tested, if they specify `REQUIRES: noncopyable_generics`.
Add a `SWIFT_STDLIB_OVERRIDABLE_RETAIN_RELEASE` CMake option. When set to true, swift_retain/release and the other functions in InstrumentsSupport.h can be overridden by setting the appropriate global function pointer, as is already the case. When set to false, those function pointers are removed and the functions always go into the default implementation.
Set `SWIFT_STDLIB_OVERRIDABLE_RETAIN_RELEASE` to false when building the minimal stdlib, and set it to true otherwise by default.
rdar://115987924
swift-evolve hasn’t been used in the recent past. @beccadax and I agreed that it doesn’t provide any value anymore to keep swift-evolve around. In Becca’s words:
> The resilience implementation is pretty stable at this point, and it never seems to have had many of the bugs that swift-evolve would have been able to shake out.
This patch adds a new build products to build and test the Swift stdlib
for WebAssembly.
This adds WebAssembly specific stdlib product instead of adding the new
target in `stdlib-deployment-targets` because unlike darwin platforms
Wasm target has quite different stdlib configuration from host target
and there is no way to specify different stdlib configuration for each
target in `stdlib-deployment-targets` for now.
This patch adds 1 new dependency `wasi-libc` and 3 new build products:
1. `WASILibc` - wasi-libc is a libc implementation for WebAssembly
System Interface (WASI). This product is required to build the
compiler runtimes and Swift stdlib.
2. `WasmLLVMRuntimeLibs` - This product builds `./runtimes` directory
in llvm-project, which contains compiler-rt, libcxx and libcxxabi.
This product is required to build Swift stdlib.
3. `WasmStdlib` - This product builds standalone Swift stdlib for
WebAssembly. (Similar to `MinimalStdlib` product, but configured for
WebAssembly target)
* swift_build_support: fix `shell.run` bytes printing
`output.splitlines()` returns a value of `bytes` type, not `str`, which leads to `b` prefixed to it when printing.
This led to broken output when running `update-checkout`. Before:
```
[swiftpm] b"Already on 'main'"
```
After:
```
[swiftpm] Already on 'main'
```
* swift_build_support/shell.py: use `errors='replace'` in `decode`
Use FetchContent to include swift-syntax directly in swift. This can be
thought of as an `add_subdirectory` for a directory outside the root.
The default build directory will be `_deps/swiftsyntax-subbuild/`, though
the modules and shared libraries will be built in `lib/swift/host` by
passing down `SWIFT_HOST_LIBRARIES_DEST_DIR` to avoid copying them as we
were doing previously.
It doesn’t really matter but the SourceKit stress tester and SwiftEvolve share the same repo and have a very similar build architecture and they should be build next to each other by build-script.
Some build scenario (e.g. lldb) want swift-syntax libraries installed
but don't want to install "swift" compiler products.
Install 'earlyswiftsyntax' products independently when
'--install-swiftsyntax' is specified but '--install-swift' is NOT
specified.
In the fullness of time, we want to split the full build-script-impl pipeline so
that we can begin moving library like products (libdispatch, foundation) from
build-script-impl into build-script. We are not there yet since some of swift's
concurrency tests have a dependency on swift dispatch being built. This breaks
the build and we need to extract those tests into a separate product. But for
now, this makes sense to repair the build.
rdar://89046735
For compiling codes required for macro support, we now need swiftc
compiler in the build machine.
Unlike Darwin OSes, where swiftCore runtime is guaranteed to be present
in /usr/lib, Linux doesn't have ABI stability and the stdlib of the
build machine is not at the specific location. So the built compiler
cannot relies on the shared object in the toolchain.
