These were isolated by interleaving operations. However, recent tweaks
to the build have removed those. Merge the adjacent sections to show the
contiguous build segment.
Build bot runtimes are very long and not fully transparent right now. In addition to the steps for build and test, we should keep an eye on Fetch-Dependencies.
Unified builds of compiler-rt together with LLVM failed for the Android SDKs. It got too complicated to redirect the way LLVM would configure the nested build-trees. Standalone builds slightly increase build time, but they turned out much simpler and we end up with less duplication of definitions.
The LLDB test suite is not very stable on Windows. In order to improve the situation, however, we need to get it tested continuously. This patch attempts to solve the chicken-egg problem. It introduces a simple override for unstable tests: list them in file `utils/windows-llvm-lit-test-overrides.txt` and SwiftCI will skip/xfail them.
This approach has a number of benefits:
* overrides don't need to be in sync with https://github.com/swiftlang/llvm-project
* overrides are tracked in one place and are not spread across the LLDB test suite
* overrides are swiftlang-specific, which clearly states the differences to upstream LLVM
* we can enable continuous testing (and get reports for new failures) without fixing the world first
Once the remaining subset of tests passes reliably, we can iterate to enable the others and increase coverage. This change implements the infrastructure. There is a separate PR to enable tests in CI, which can be reverted with fewer side-effects.
Add support to `Build-CMakeProject` to use the GNU driver on Windows.
This is preparatory work to get the experimental runtime build working
(and subsequently enable a static SDK for Windows). It also opens the
possibility to explore the performance gap between MSVC and clang.
This hoists the cleaning to prior to building the toolchain. This is
particularly important as changes in the module format may cause the
compiler to crash. Due to the use of Swift in the Swift compiler, we
load modules early and a previous run may have left over modules from
the last run, which would result in the module attempting to be loaded.
This cleans out the extra modules before the toolchain build avoiding
that.
Clear out the android builds as well as any leftovers from a previous
test run which would possibly break the build in the case that the
compiler was updated.
Build System as static as it has been internalised into SPM and no
longer needs to be shared across multiple targets. This reduces the
number of distributed files and helps reduce the binary size (~56KiB).
SwiftSystem is only used in a single location in SPM, allowing us to
collapse the file into the single site. This reduces the overall
toolchain size by ~56K. It also removes the need to ship the extra DLL.
This allows us to add an identifier to the toolchain on Windows similar
to the swift.org toolchains generated on macOS. The newly introduced
identifiers should help support having parallel installable toolchains.
The command-line length to compile SwiftFoundation for arm64
exceeds the maximum command-line length on Windows.
Force CMake to use a response file to get around this limitation.
* Make pointer bounds non-experimental
* Rename @PointerBounds to @_SwiftifyImport
* Rename filenames containing PointerBounds
* Add _PointerParam exception to stdlib ABI test
* Add _PointerParam to stdlib API changes
* Rename _PointerParam to _SwiftifyInfo
Update the property to include the SDK MSI for Windows as we start
adding additional platforms. Update the file name patterns to reflect
the new naming.
There is no guarantee that `cmake` is available in the path. CMake may
be provided through VS or the VS Build Tools, in which case, you must be
in a VSDevCmd environment to invoke `cmake`. This adds quite a bit of
complexity for little gain as the projects will check of the minimum
version required (`cmake_minimum_required`).
