`:` is not a valid file system character but is used to namespace the
imported targets. This is then used to create the stamp file. Sanitize
the name prior to use as a stamp file name.
"Support Macros in Linux" patches was inconsistent with checking
platforms. Some only checked 'LINUX' but some matches
'LINUX|ANDROID|OPENBSD|FREEBSD'. Although I don't have tested other
platoforms than Linux at all, there's no reason to limit it to Linux.
So use the consistent check to match 'LINUX|ANDROID|OPENBSD|FREEBSD'
swift-compatibility-symbols, swift-def-to-strings-converter,
and swift-serialize-diagnostics don't use any Swift modules. But when
SWIFT_SWIFT_PARSER was enabled, they are linked with swiftCore. But
these binaries can be executed before the runtime is being built.
We need to stop them linking with swiftCore.
In Linux. Instead of setting temporary "fallback" RUNPATH, Set
LD_LIBRARY_PATH to builder's runtime when building standard library.
So we don't need to strip the temporary RUNPATH when installing.
For compiling codes required for macro support, we now need swiftc
compiler in the build machine.
Unlike Darwin OSes, where swiftCore runtime is guaranteed to be present
in /usr/lib, Linux doesn't have ABI stability and the stdlib of the
build machine is not at the specific location. So the built compiler
cannot relies on the shared object in the toolchain.
LLVM install_symlink takes a new argument on whether to create a symlink
or copy binaries when run. -- https://reviews.llvm.org/D145443
The variable that controls this in LLVM is `LLVM_USE_SYMLINKS`, which
defaults to `ON` on Unix-y hosts, but otherwise is false so that Windows
works. This is a configurable option, so Windows configs that can
support symlinks can take advantage of symlinks and save some space.
`LLVM_USE_SYMLINKS` is not exported from LLVM though, so we can't see
it to use. Instead, we have `SWIFT_USE_SYMLINKS`.
Rationale: we are using Swift compiler as a library in a downstream project and having these exposed would streamline version detection for our use case.
Additionally, this PR makes CMake config a bit more uniform with LLVM/Clang configs.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
MSVC 17.6p3 introduced new ARM64 intrinsics for atomic
(load-acquire/store-release) operations. Since clang does not support
this yet, force the fallback path to temporarily unblock the build while
we implement support for the `__stlr[8|16|32|64]` intrinsics in clang.
See: llvm/llvm-project#62103
We need to pick up the `_swift_tsan_xxx` symbols from libswiftCore in
most cases, but sometimes we're statically linked and in that case we
want to use a local copy.
rdar://1106655213
`.swiftmodule` is listed as an output of pure swift libraries, but it
isn't updated if there's been no changes (just like the library and
its object files). Add it to the touch hack as well.
Swift *executables* also list `.swiftmodule` as an output, even though
one isn't generated at all. Add a new POST_BUILD command to touch it
regardless.
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.
