llvm-symbolizer is critical to ASAN/LSAN properly reading and applying
allowlists and suppressions. Without properly symbolized backtraces,
the tools cannot match stack traces to suppression lists, leading to
false negatives in leak detection and other issues.
Ensure that it's installed in the toolchain presets.
This enables `swift run` and `swift test` to use WasmKit when cross-compiling to Wasm with Swift SDKs that have toolsets pointing to WasmKit.
rdar://150382758
Use it in the linux CI presets to set them to Debug mode and speed up
the linux CI, plus add a new preset which keeps building them in Release
mode.
I was looking at a passing linux CI run and saw the log timings at the
end: it takes [longer to build and test the swift-foundation repos than
to compile all 7k+ mostly C++ files in
LLVM](https://ci.swift.org/job/swift-PR-Linux/18996/console)!
```
--- Build Script Analyzer ---
Build Script Log: /home/build-user/build/.build_script_log
Build Percentage Build Duration (sec) Build Phase
================ ==================== ===========
9.2% 1132.94 Running tests for foundationtests
9.1% 1120.57 linux-x86_64-swift-build
9.0% 1104.2 Building llvm
7.2% 878.84 Running tests for swiftfoundationtests
6.5% 796.81 Running tests for swiftpm
5.6% 684.7 Building swiftpm
5.5% 667.92 linux-x86_64-swift-test
4.9% 597.64
```
Looking at the log, building swift-foundation in release mode takes a
long time, so let's see if changing it to debug mode helps. Some
background - the Foundation repos are built twice on the linux CI: once
by CMake, which is the version installed in the toolchain, then a second
time by SwiftPM purely for testing.
This pull only affects that second SwiftPM build for testing, which is
not shipped in the final toolchain but thrown away.
The existing swift-cmake-options flag overwrites all flags computed by
build-script. Sometimes it is useful to be able to append additional
CMake flags without overwriting the existing flags.
This patch adds `--extra-swift-cmake-options` that adds the specified
flags to the Swift CMake configuration instead of overwriting them.
This also adds a similar `--extra-llvm-cmake-options`, which adds the
new flags to the end, allowing one to replace and overwrite CMake flags
that build-script computed.
Due to the parameter passing mechanisms in build-script-impl, while this
behavior would be useful for Swift, it is not immediately apparent how
one would best implement this at this time.
The concurrency runtimes require that dispatch is installed or it will
fail to load at launch. The C library is built as part of the
concurrency build but is not installed. We need to install a copy of
dispatch so that programs that link concurrency run.
Adding a stage-2 preset. This preset adds SwiftPM and XCTest to the
built products. The stage-1 preset could likely build all of the
product, but because the stage-1 compiler was built without several
optimizations available in the stage-0 compiler, this compiler will not
be as performant as a separate stage-2 compiler.
Adding a stage-1 buildbot preset and updating the stage 0 preset to
install the stage0 bootstrap somewhere so that it can be used to
bootstrap the stage-1 toolchain.
This preset builds the compiler and standard library on a system without
an existing Swift.
Note, there are many issues with it and it won't be able to pass tests.
It is an intermediate product that will need to build a compiler with
the Swift sources. The stage-0 compiler won't be able to build the
driver as the driver depends on Foundation, which requires macro support
and the stage-0 compiler does not have macro support. It will need to
build swiftsyntax though to give the stage-1 compiler macro support.
The stage-1 compiler then can build a stage-2 toolchain with most of the
libraries and runtimes. That stage-2 toolchain should then be capable of
building the full nightly toolchain package.
What is nice about this is that by not using extra-cmake-args, we can avoid
passing this into LLVM as well when attempting to reproduce failures on the bots
(thus avoiding having to rebuild LLVM as well).
Keep mixin_swiftpm_base as the base of SwiftPM and all dependents, but
then separate the SwiftPM + package bases and their respective
platforms.
This allows SwiftPM to add its own changes without impacting downstream
packages (eg. the recently added cross compile setting).
When adding a Swift Testing test to Swift PM repository, the `test`
portion of t he OSX package pipeline was building against x86_64 and
arm64.
Ensure Swift PM testing only runs against the host platform
architecture.
This patch enables the new runtime build in macOS smoke testing in CI.
This is only ensuring that the default configuration builds and does not
enable anything fancy at this time.
Somehow the new build system is affecting the old build system in such a
way that it's not producing the Swift Concurrency runtime for smoke
testing, resulting in test failures due to the missing library.
```
/Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/build/buildbot_incremental/llvm-macosx-x86_64/bin/llvm-nm: error: /Users/ec2-user/jenkins/workspace/swift-PR-macos-smoke-test/branch-main/build/buildbot_incremental/swift-macosx-x86_64/lib/swift/macosx/x86_64/libswift_Concurrency.dylib: No such file or directory
```
This isn't even a directory that is affected by the new build, but
disabling to try to bring things back up.
Various projects (vapor in particular) now depend on swift-testing. The
current Xcode installation doesn't contain it and we're not building it,
so they're failing. Update the base compat suite preset to also build
swift-testing (and its macros).
Fixed an issue in the convenience wrapper that resulted in building all
copies of the standard library for the default compiler architecture
instead of the desired architecture. To fix this, we pull the desired
target triple and deployment target from the existing variables and pass
that into the CMake invocation.
