When building Swift code into the compiler (e.g, the new Swift parser
along with macros support), make sure we always add the appropriate
paths to (1) link against the host Swift toolchain, and (2) find the
host Swift libraries (such as SwiftSyntax) at runtime.
The CMake code for doing this was only running for Darwin builds, so
generalize it to also work on Linux.
Some versions of the swift driver have a bug where passing `-sanitize=`
does not emit the correct `-fsanitize=` flag for the clang link step.
Although this is being fixed, we must be able to correctly build with older
versions of the swift driver for some period of time. We workaround that
issue by explicitly passing the correct `-fsanitize=` argument
ourselves.
This works around rdar://107733898
swift_supports_implicit_module invokes /path/to/toolchain/usr/bin/swiftc
directly without using `xcrun`. That fails to set necessary
environmental variables to make swiftc infer the SDK path. Because of
that swift_supports_implicit_module used to fail because the test
compilation fails to load the stdlib. This PR workaround it by passing
`-parse-stdlib` to avoid implicit stdlib loading.
Our libraries have a `LC_LINKER_OPTION` for eg. `-lswiftLLVMJSON`.
This is resolved (probably just based on the actual libswiftLLVMJSON.a
added to the link command) by ld, but not by lld. Add in a link
directory so that these libraries can be found.
* Move `add_pure_swift_host_library()` from lib/CMakeLists.txt to
AddPureSwift.cmake so that code outside `lib` can use it
* Add `add_pure_swift_host_tool()` function to make a pure Swift
host executable target (for future usages)
* Specify depending `SwiftSyntax` modules explicitly because not all
Swift libraries uses all SwiftSyntax libraries
For future usage from other host libraries written in Swift
For CMake:
* Explicitly specify LINKER_LANGAGE to CXX in existing components so
that 'swiftc' is not used when linking with 'swiftASTGen'
* Add 'EMIT_MODULE' argument to 'add_pure_swift_host_library' to emit
.swiftmodule usable from other Swift libraries.
For unified builds, LLVM with the update to stable/20221013 includes its
own FindLibEdit, which shares many of the same names than Swift's
FindLibEdit, except that they differ in the target name.
Match both LLVM and Swift target names, so unified builds can find
LibEdit::LibEdit correctly and not try to link against libedit
mistakenly.
This should not affect Darwin/Linux builds from upstream Swift, since
they build non-unified in most people setups (including CI).
Once the API has gone through Swift Evolution, we will want to implicitly
import the _Backtracing module. Add code to do that, but set it to off
by default for now.
rdar://105394140
We're going to add a program, `swift-backtrace`, that gets built alongside
the stdlib and the runtime, and that needs to be installed in libexec/swift
alongside the libraries in lib/swift.
It wants to be built with the stdlib/runtime because there's an internal
interface between `swift-backtrace` and the runtime, so the program needs
to stay in lock-step with the runtime library.
rdar://105390807
This allows us to evolve e.g. token kinds and how attributes are modelled independently between SwiftSyntax and the compiler. It also makes it easier to e.g. add an attribute because you don’t need to create PRs for two repositories.
We would previously use `clang-cl` without the explicit path which could
find an alternative `clang-cl` instance. This manifested as a failure
to build libdispatch as part of the compiler when cross-compiling x64 to
arm64.
and match the usage pattern employed by other LLVM projects.
For context about the underlying change see https://reviews.llvm.org/D117977
Addresses rdar://101396797
(cherry picked from #61769, commit 2763cc3911)
