On older x86_64 hardware, this isn't a problem since CET IBT hardware
support may not have been available. However, newer x86_64 hardware
supports the feature, which will lead to BTCFI failures. Therefore ensure
the same BTCFI disabling logic applies on x86_64 as well as aarch64.
For hosts that have a swiftly-managed Swift compiler, we could not
bootstrap using those tools, because of some hardcoded assumptions
about where the `/lib` directory lives, relative to the `/bin`
directory that contains the detected `swiftc`.
This patch adds specific support for detecting when the `swiftc`
is coming from a swiftly install and uses the correct paths.
I've tested this patch on my Linux machine that has swiftly 1.0.1,
with the Swift 6.1.2 toolchain.
The SimplifyCFG and LoopRotate passes result in verification failures
when built in a compiler that is not built with Swift sources enabled.
Fixes: rdar://146357242
This patch adds initial support for Emscripten SDK alongside the existing
support for WASI SDK. This is a first step towards building a part of
Swift compiler for Emscripten target (which will be used to build LLDB
with Swift to WebAssembly target).
This was quite brittle and has now been superseded
by swift-xcodegen. Remove the CMake/build-script
logic for it, leaving the option behind to inform
users to switch to using xcodegen instead.
For C/CXX targets, sanitizer options are set by 'CMAKE_{C|CXX}_FLAGS' in
HandleLLVMComfig.cmake. However for Swift targets, they are set for each
target. That caused some mismatch issues. Instead set them globally for
Swift targets too.
rdar://142516855
This means we will get build IDs in the tools and standard library,
which is useful for debugging (it lets us associate debug symbols with
the binaries later on, as well as allowing us to reliably identify
exactly which binary we are looking at).
rdar://116525111
Separate swift-syntax libs for the compiler and for the library plugins.
Compiler communicates with library plugins using serialized messages
just like executable plugins.
* `lib/swift/host/compiler/lib_Compiler*.dylib`(`lib/CompilerSwiftSyntax`):
swift-syntax libraries for compiler. Library evolution is disabled.
* Compiler (`ASTGen` and `swiftIDEUtilsBridging`) only depends on
`lib/swift/host/compiler` libraries.
* `SwiftInProcPluginServer`: In-process plugin server shared library.
This has one `swift_inproc_plugins_handle_message` entry point that
receives a message and return the response.
* In the compiler
* Add `-in-process-plugin-server-path` front-end option, which specifies
the `SwiftInProcPluginServer` shared library path.
* Remove `LoadedLibraryPlugin`, because all library plugins are managed
by `SwiftInProcPluginServer`
* Introduce abstract `CompilerPlugin` class that has 2 subclasses:
* `LoadedExecutablePlugin` existing class that represents an
executable plugin
* `InProcessPlugins` wraps `dlopen`ed `SwiftInProcPluginServer`
* Unified the code path in `TypeCheckMacros.cpp` and `ASTGen`, the
difference between executable plugins and library plugins are now
abstracted by `CompilerPlugin`
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)
```
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
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
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
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.
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.
Add the swiftmodule paths for ASTGen via
`-add_ast_path` to the public linker flags such
that downstream linking picks them up, allowing
LLDB to load them when debugging. Also switch
SwiftCompilerModules to using public linker
flags instead of adding the linker flags in
`_add_swift_runtime_link_flags`.
When we're building with host tools, we should use the host's swiftrt.o
and not the one we've just built when we're trying to build tools that we
will run on the host system.
rdar://115774613
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.
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.
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.
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
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
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.
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.
