This fixes a build that passes `-D SWIFT_STDLIB_SUPPORT_BACK_DEPLOYMENT=NO` and `-D BOOTSTRAPPING_MODE=BOOTSTRAPPING-WITH-HOSTLIBS`.
Previously a few CMake errors would be emitted:
```
CMake Error at cmake/modules/AddSwift.cmake:478 (get_property):
get_property could not find TARGET HostCompatibilityLibs. Perhaps it has
not yet been created.
CMake Error at cmake/modules/AddSwift.cmake:527 (add_dependencies):
add_dependencies called with incorrect number of arguments
Call Stack (most recent call first):
cmake/modules/AddSwift.cmake:969 (_add_swift_runtime_link_flags)
tools/driver/CMakeLists.txt:23 (add_swift_host_tool)
```
In apple/swift#71135 I added this code to `add_pure_swift_host_library`
but failed to realize that it was also needed in
`add_pure_swift_host_tool`. Extract the code into a helper function and
invoke it from both functions in order to be able to instrument the
`swift-plugin-server` and other pure Swift tools.
Currently those are hardcoded to `-g`, but in some Apple internal
configurations we would like to change them.
There are other part of the build system that hardcode `-g`
(e.g. in `SwiftCompilerSources` and `AddSwiftStdlib.cmake`),
but we are not interested in those at the moment -- we will address those
in the future if need be.
Supports rdar://127503136
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
Locally I build debug builds without the standard library,
using a copy of the stdlib in my release build. This hit
a CMake error here since the `HostCompatibilityLibs` target
isn't defined. Update to only access it when doing a bootstrapping
build.
At the time I implemented #60728, I did not realize that in all the
bootstrapping mode we need to depend on the compatibility libraries we
build -- otherwise when targeting a low deployment target we risk
failing because we are not able to find such libraries.
Addresses rdar://126552386
If we're on a system that has ld.gold 2.35 or earlier, we want to use
lld instead because otherwise we end up with duplicate sections in the
output.
rdar://123504095
This is needed in specific Apple internal configurations -- as a result
of the limited applicability, this option is not exposed through
`build-script` on purpose.
Addresses rdar://127014753
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.
The WASI community is transitioning to a new naming for the "preview"
version in the target triple: wasm32-wasi -> wasm32-wasip1.
At this moment, we keep the old triple wasm32-wasi because it's already
widely used, but we should start using the new triple threaded target.
LLVM checks only if the OS field *starts* with "wasi", so "wasip1" is
still considered a valid `isOSWASI()` target.
See: https://github.com/WebAssembly/wasi-libc/pull/478
Such module usages are not relevant for the final build, they are used
only to detect the capabilities of the compiler.
This generalizes #68453, and would be needed for Apple internal
configurations that set `SWIFT_LOADED_MODULE_TRACE_FILE` when building
the compiler.
Addresses rdar://124954349
The output of build-script on macOS is currently full of spammy linker warnings
like this:
```
ld: warning: ignoring duplicate libraries: '.../swift-project/build/Ninja-RelWithDebInfoAssert/llvm-macosx-arm64/lib/libLLVMDemangle.a', 'lib/libswiftDemangling.a'
```
Apple's linker complains about duplicate libraries, which CMake likes to do to
support ELF platforms. To silence that warning, we can use
`-no_warn_duplicate_libraries`, but only in versions of the linker that support
that flag.
In several places, there was the same or similar code to either do
a symlink or use copy/copy_if_different/copy_directory in Windows
systems. The checks were also slightly different in some cases.
There is a `SWIFT_COPY_OR_SYMLINK` that can be controlled as a CMake
option, and uses `CMAKE_HOST_UNIX` as default. Change all cases that
I can find to use that value. Also create a parallel value
`SWIFT_COPY_OR_SYMLINK_DIR` to apply to directories.
There is still a couple of cases that are specific to macOS SourceKit
framework which I have left as-is, since symlinks is probably the only
right thing to do there.
There's a case for Windows specifically that uses symlinks (in
523f807694/cmake/modules/SwiftConfigureSDK.cmake (L502))
which I have not modified as well.
This patch adds a new CMake option, `SWIFT_ENABLE_WASI_THREADS`, to
enable building the Standard Library using WASI threads primitives
(https://github.com/WebAssembly/wasi-threads). With this option, the
Standard Library will be built for the new "wasm32-unknown-wasi-threads"
target. We add the new triple because the WASI threads proposal requires
extra syscalls and object files compiled to "wasm32-unknown-wasi" and
"wasm32-unknown-wasi-threads" are not compatible and cannot be linked
together.
Don't try to build dynamic libraries if the SDK only supports
static linking. Also, *do* build static libraries if the SDK
only supports static linking.
rdar://123503191
Add cross-compilation flags for the newly added Swift source in `lib/ASTGen/`,
similar to how `SwiftCompilerSources/` is already cross-compiled for other
platforms. Make sure the Swift source in the compiler builds and links against
`SWIFTLIB_DIR` in this cross-compilation build directory, not the one that comes
with the native host compiler.
This requires changing the dependency chain in `CROSSCOMPILE` mode, as normally
the Swift compiler is built first when building natively for the host, then it's
used to build the stdlib. However, when cross-compiling the toolchain, the stdlib
must be cross-compiled first by the host compiler, then the portions of the
Swift compiler written in Swift must be cross-compiled with that new stdlib. All
these dependency changes simply change that compilation order when cross-compiling,
including removing the dependency that the Swift compiler is built before the
stdlib when cross-compiling the Swift compiler.
All changes in this pull are gated on the `CROSSCOMPILE` mode, so they will
not affect any of the existing CI or build presets.
If one is building Swift against an instrumented LLVM build, when the
functions in AddPureSwift.cmake tries to link Swift code that also links
LLVM instrumented code, the linking will fail because the linker will
not use the profiling runtimes.
The modifications replicate the existing code in LLVM
HandleLLVMOptions.cmake, but adapted to Swift variables where possible.
The necessary arguments are forwarded through `-Xclang-linker` because
the spelling of the Swift driver does not give access to all the options
that Clang provides.
This has been tested with an unified build, but a standalone build could
still pass the `LLVM_*` variables to the Swift build system to make use
of this code.
This allows us to build swift-format with dynamic linking against the
toolchain build of the swift-syntax and swift-argument-parser packages.
Wire up the swift-markdown build and hoist the swift-format build prior
to sourcekit-lsp. This sets us up for supporting swift-format based
formatting in the LSP.
This library uses GenericMetadataBuilder with a ReaderWriter that can read data and resolve pointers from MachO files, and emit a JSON representation of a dylib containing the built metadata.
We use LLVM's binary file readers to parse the MachO files and resolve fixups so we can follow pointers. This code is somewhat MachO specific, but could be generalized to other formats that LLVM supports.
rdar://116592577
