This used to overwrite the RUNPATH when copying libraries from
earlyswiftsyntax directory. Since earlyswiftsyntax is now replaced with
FetchContent, we don't need this anymore
Use FetchContent to include swift-syntax directly in swift. This can be
thought of as an `add_subdirectory` for a directory outside the root.
The default build directory will be `_deps/swiftsyntax-subbuild/`, though
the modules and shared libraries will be built in `lib/swift/host` by
passing down `SWIFT_HOST_LIBRARIES_DEST_DIR` to avoid copying them as we
were doing previously.
The dispatch that's built into concurrency on Linux and Windows is built
with clang, but there's no dependency edge. Usually this isn't noticed
because concurrency and most the things it depends on also depend on
clang directly, but occasionally ninja will choose the dispatch build
before building other dependencies, which then fails because there's no
clang.
In some internal configurations we set the
`SWIFT_LOADED_MODULE_TRACE_FILE` environment variable when running the
build of the compiler -- as a result, this causes `-parse` to always
fails, preventing to detect properly if we can use `disable-implicit*`
flags.
Addresses rdar://115338219
Instead of letting CMake set RPATH of the test executables, use
INSTALL_RPATH and BUILD_WITH_INSTALL_RPATH just like other executable
and shared libraries.
Previously when a swift module link with exported swift-syntax targets e.g.
'SwiftSyntax::SwiftParser', the libraries in earlyswiftsyntax were used
instead of the copied libraries in the swift build directory. That
wasn't ideal.
This wires up the new macro properly into the build machinery to ensure
that the `distribution` target properly builds and installs the
dependencies. This fixes the missing `swift-plugin-server` on Windows.
Account for import libraries and the associated layout difference on
platforms (e.g. DLLs are placed in `bin`). This is required to enable
building the macro path on Windows.
`:` 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.
Windows builds in waves:
- build build tools
- build tools (compilers, debuggers, linkers, assemblers)
- build runtimes (Swift runtime, standard library, experimental libraries)
- build core libraries
- build Swift tooling
We do not need to build the C++ interop module at the moment when
building the tools. This disables that and the extra content which
currently does not result in any artifacts.
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
