Simplify the `Build-Testing` call to simply build swift testing for
distribution. The testing support was never implemented and there was
more duplication than necessary.
This split reduces the logic and changes nearly all the handling into
path computation. It also will enable us to migrate towards avoiding a
separate staging step.
Use a structural definition of the settings and convert them to the
appropriate serialised format as a delayed operation. This makes it
easier to read the settings and modify them as we iterate on the
toolchain.
Take the opportunity to extract the PList conversion into a helper
function.
The backtracing code will warn you if you attempt to forcibly enable
backtracing for a privileged executable. This is apparently upsetting
the Driver/filelists.swift test.
Since we want to force it on for tests, so that we will definitely get
backtraces, add an option to suppress warning messages, and turn that
on for tests as well.
rdar://144497613
This further migrates towards a shared installation of the platform and
SDKs staging. This helps ensure that we are properly creating additional
SDKs without overwriting components and can share components across
builds. It also avoids unnecessary duplicated work.
* util: Add -Variant param to build.ps1 for building Asserts | NoAsserts.
* Special case BinaryCache path concatenation.
* Fix merge damage.
* Cleanup.
* Update update-checkout-config.json
Update swift-system requirement to 1.4.0. This is motivated by swift-build which requires swift-system 1.4.0. More importantly, the API surface between 1.3.0 and 1.4.0 changed including the API usage that is required by swift-build.
* Update update-checkout-config.json
Update to 1.4.1
- Add FallbackLibraryPaths to usr/bin - swift-build uses this to lookup dlls like libclang
- Fill in the version field used to construct runtime library paths
The only currently known constraint on the build path is the compilers
build. Use long paths for the builds, co-locating more build products
and allowing better re-use of the build content. This makes it easier to
adjust the various targets that we are building without having to force
clean builds due to changes in the build mapping.
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).
`os._exit` does not run any cleanup handlers or flush any buffers, which
means that we may end up missing helpful log output. It was being used
to avoid printing the log analysis when `--help` was passed, but we can
have the same behavior by just not using `finally`.
This adds the `swift_Concurrency` module to the new runtimes build. This
is sufficient to build the code but will require further fine tuning to
ensure that all the flags entirely identical and that the ABI surface is
also fully replicated.
The nightly toolchains on Windows improperly versioned the installation
to 6.0.0 (which would collide with an official 6.0.0 release 😱).
In order to use the toolchain as a pinned toolchain we need to account
for the path change. Add a workaround to allow using the extracted
toolchain snapshot.
I have been doing this using extra-cmake-args/etc... just feels better to have
an actual option to do this.
Just did this quickly while waiting for my Linux build to finish that uses
extra-cmake-args to set the linker.
* Include `DeclContext` of the node where possible
* Add 'default-with-decl-contexts' dump style that dumps the dect context
hierarchy in addition to the AST
* Support `-dump-parse` with `-dump-ast-format json`
