This is a tool specifically designed to generate
Xcode projects for the Swift repo (as well as a
couple of adjacent repos such as LLVM and Clang).
It aims to provide a much more user-friendly experience
than the CMake Xcode generation (`build-script --xcode`).
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
Currently the test assumes that when we are testing for macOS we are
targeting the host architecture (since we need to reuse existing build
products to contain testing time) -- however there are some Apple
internal configurations in which that's not the case.
Addresses rdar://118337598
These builds do not work outside of darwin currently. Rather than adding
the skip to all the necessary build presets, just disable in the product
instead.
This is needed short term to allow the test to pass when running on
Python 3.11 and later and avoid errors like
```
<stdin>:44:1: note: non-matching line after previous match is here
<string>:1: DeprecationWarning: 'pipes' is deprecated and slated for removal in Python 3.13
^
```
Long term we want to replace uses of the obsolete `pipes.quotes`
function with `shlex.quotes`.
Addresses rdar://109664710
The current implementation currently requires to have physical machine
for each architecture supported by macOS, which is not desirable.
To allow all cases to be tested on a random Mac machine, allow
to inject an arbitratry current architecture into the inference
of the cross compile hosts by means of an environment variable.
Addresses rdar://99096874
Otherwise, we can't successfully dry-run a toolchain on darwin.
I added an option enable-extract-symbol-dry-run-test that can be set to restore
the previous behavior and updating the BuildSystem unit tests that depend on
that behavior to pass that flag.
It makes sense to just set this here since we aren't testing that functionality
and enables us to test this if we aren't using one of the specified Xcodes
(which can be useful).
This is where I am going to put the stage 2 swift. The reason why I need to do
this is that I need libdispatch, foundation, etc on Linux to use the stage2
compiler.
The key thing here is that by using this builder, I am going to be able to split
the build-script-impl pipeline in two and put in a build-script pipeline in
between. This is needed so that on Linux, we can build the stage 2 compiler
before we build any of the build-script-impl libraries that depend on having a
swift compiler.
This should be an NFCI change. I am relying on our build system unit tests to
ensure that I am not changing any real behavior.
Add three new flags, '--skip-clean-libdispatch', '--skip-clean-foundation', and
'--skip-clean-xctest', that leave the previous builds of those products in place.
Pass the Swift and CMake flags needed to cross-compile Foundation and so on, with
the first example of Android. Add a new flag, --cross-compile-deps-path, which is
used to search for cross-compiled libraries, like libcurl, that the corelibs
depend on. Also add a new flag, --common-swift-flags, to pass additional Swift
flags to the corelibs.
We should re-enable this once it is clear that there aren't issues with the
Xcode generator/host side swift cmake. The Ninja generator (the default) still
is enabled.
The reason why I am doing this is that we do not yet have on all of the
non-Darwin bots swift host toolchain files. So we can't test this code path on
those platforms and thus can not guarantee correctness. The result is that on
those other platforms if someone /does/ have a host toolchain with a swift
binary in it, failures may result breaking other people's builds.
There are three things going on here (note all on Darwin):
1. If one compiles a swift static library and links the static library into a
cxx executable, the cxx executable will need the -L flags to find the
appropriate libraries in the SDK/toolchain.
2. I fixed an rpath issue where due to old code I didn't understand/propagated
forward, we were setting the rpath to be the -L directory in the appropriate
SDK. After reasoning about this a little bit I realized that this was code
that was actually intended to be used for target libraries (for which the
given rpath would be correct). On the host side though on Darwin, we want to
use the rpath for the standard stabilized stdlib on the system.
3. I added Build System Unittests to ensure that this keeps on working. I also
added test cases that I should have added before. I just had never thought
about how to test this and I realized this method would work and would
prevent regressions while I am waiting for a new swiftc with driver fixes to
land.
