Conflicts:
- `test/Interop/Cxx/class/method/methods-this-and-indirect-return-irgen-itanium.swift`
previously fixed on rebranch, now fixed on main (slightly differently).
Don't use the just-built clang on macOS. macOS does this more "right"
than the Linux build. Linux will sometimes use the just-built
Swift-driver with the just-built clang, but sometimes would use the
system clang instead. macOS uses the toolchain Swift-driver with the
toolchain clang. This is correct, but it means that if we force the
other clang, we'll get mismatched sanitizer runtimes so the ASAN bot
will fail.
It we're not building clang, the swift driver silently dies and fails to
build. While it shouldn't do that, we should also only tell it to use a
clang that exists. If we're not building clang or the "native" clang
doesn't exist, leave the environment variable unset and let the driver
choose something.
The just-built Swift driver was picking up the system clang, which would
try to use the bfd linker instead of gold or lld. bfd doesn't like how
Swift handles protected symbols and fails with the following error:
```
error: link command failed with exit code 1 (use -v to see invocation)
/usr/bin/ld: /home/build-user/build/buildbot_linux/libdispatch-linux-x86_64/src/swift/CMakeFiles/swiftDispatch.dir/Block.swift.o: relocation R_X86_64_PC32 against protected symbol `$s8Dispatch0A13WorkItemFlagsVSYAAMc' can not be used when making a shared object
/usr/bin/ld: final link failed: bad value
```
This patch tells the Swift-Driver where it should find its clang, and
makes it match the clang that is in use through the rest of the build.
Fix some indentation issues.
Change `build-script-impl` to make `build-linux-static` a positive argument.
Fix documentation for `--linux-archs` and `--linux-static-archs` (the options
are comma separated for `build-script`, but semicolon separated for
`build-script-impl`).
Set the default for `linux-static-archs` to `x86_64, aarch64` so that we
install the expected content in the toolchain.
Add missing default for `test_linux_static`.
Make sure to pass down `--skip-build-linux` and `--build-linux-static`.
Factor out config file generation and call it from the install step in `llvm.py`
as well as from the build step.
rdar://123503470
Declare a new `LINUX_STATIC` SDK and configure it.
Add options to set the build architectures for the `LINUX` and
`LINUX_STATIC` SDKs, similar to what we have for Darwin, because
we'll be cross-compiling.
Also add an option to point the build system at the sources for
the musl C library, which we're using for `LINUX_STATIC`.
rdar://123503470
Conflicts:
lib/Basic/Platform.cpp
```
diff --git a/lib/Basic/Platform.cpp b/lib/Basic/Platform.cpp
index 240edfa144a..1797c87635f 100644
--- a/lib/Basic/Platform.cpp
+++ b/lib/Basic/Platform.cpp
@@ -200,10 +200,7 @@ StringRef swift::getPlatformNameForTriple(const llvm::Triple &triple) {
case llvm::Triple::CUDA:
case llvm::Triple::DragonFly:
case llvm::Triple::DriverKit:
-<<<<<<< HEAD
case llvm::Triple::ELFIAMCU:
-=======
->>>>>>> main
case llvm::Triple::Emscripten:
case llvm::Triple::Fuchsia:
case llvm::Triple::HermitCore:
```
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.
`-external-plugin-path` flags pointing XcodeDefault.xctoolchain were
needed to use macro plugins in Apple SDK. But since Apple macro plugins
are not in `.xctoolchain` anymore, these flags are useless.
rdar://125498074
We don't currently support building resilient relative protocol witness tables.
One might want to build with relative witness tables but not need
resilient protocols. Allow for that scenario.
Add a test configuration to test library-evolution + fragile resilient
protocols + relative protocol witness tables.
In the presence of multiple `--filter` options, `llvm-lit` will only
pick the last one. Which means we only ever ran the tests under
`commands/`.
This patch turns the multiple filters into a regex.
