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.
MSVC 14.43 added a requirement for Clang 18, which is not currently
supported by any Swift toolchain version. This updates the condition for
setting the `_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH` compiler define
for MSVC 14.43 and higher.
Building SwiftCompilerSources with a Swift 5.8 compiler is not tested anymore, and it might showcase bugs in the old compiler version that are already fixed.
This bumps the minimum allowed version to Swift 5.9, which was shipped in Xcode 15.
VS 17.10 introduced a requirement on Clang 17, but the pinned Swift
toolchain used to bootstrap the compilers (a 5.10 snapshot) uses Clang 16. We
can relax this version requirement with ALLOW_COMPILER_AND_STL_VERSION_MISMATCH
which needs to be set for all CMAKE_Swift_FLAGS when building the
compilers, as well as explicitly in SwiftCompilerSources as the
invocation of swiftc there is via custom_command
The new `swift-driver` seems to enqueue a `wrapmodule` job which uses
the given `module-name` to form the output file name when not doing
optmizations (seems to happen only for `-Onone` in my testing). Since the
CMake functions macros are using the module name also as the explicit output
name, this clashes and ends up in an unhelpful error message from the driver.
```
SwiftDriverExecution/MultiJobExecutor.swift:207: Fatal error: multiple
producers for output ... SwiftCompilerSources/Basic.o: Wrapping Swift
module Basic & Compiling Basic SourceLoc.swift
```
This was reported in https://forums.swift.org/t/debug-swift-build-fails/71380
The changes use a different output object name (by using `.object.o`
suffix) which does not clash with what the `swift-driver` does
automatically. The code around the output objects and the static
libraries have to change slightly to handle this case.
Additionally, the resulting library when in `Debug` is now declaring its
dependency on `swiftSwiftOnoneSupport`, to avoid linking errors when the
libraries are used in the final binaries.
Debug mode seems to enable PURE_BRIDGING_MODE, which seems to skip
transitively including some C headers that files like
`Utilities/Test.swift` depend on. To avoid errors building, add the
missing include in a new `#else` branch.
I think CI will not test the `Debug` mode, so the only thing that it can prove is
that these changes do not break the `Release` mode.
legacy layouts must be copied before the bootstrapping compiler is used to build the SwiftCompilerSources
Fixes a sporadic build failure due to missing legacy layout files
When building with a Swift 5.9 toolchain, we can specify the
`-cxx-interoperability-mode` flag instead of the deprecated
`-enable-experimental-cxx-interop` 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.
Changes to the headers imported by Swift files aren't not correctly
propagated in CMake/Ninja. So changes to C/C++ headers didn't rebuild
ASTGen modules. Move the similar hack from SwiftCompilerSources and use
it in ASTGen as well.
rdar://120863405
Update the #include in generated HeaderDependencies.cpp so it doesn't
need a special include path that points into `include/swift`. In the
swift sub-directory, there is a `Strings.h` that can be mistaken as
<string.h> on a case-insensitive file system.
rdar://119997353
`HeaderDependencies.cpp` is (as in the name) C++, which means it
receives `-DSWIFT_TARGET` from the top level `add_definitions`. No need
to add it again.
`llvm::None` is deprecated, but still being used in Swift until we have
fewer 5.10 cherry-picks. Add the `SWIFT_TARGET` definition to ignore the
deprecation.
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`.
The calculated arguments for compiling the SwiftCompilerSources works in
the cases where the sysroot of the machine building the code is `/` or
can be provided as a single directory in `SWIFT_SDK_<HOST>_<ARCH>_PATH`.
For some cases in which a sysroot is split into multiple directories or
in some cross-compiling scenarios where the SDK layout is beyond our
control, we can provide more flexibility in the build system.
The changes in this commit moves the calculations around the SDK and
libc++ outside the `add_swift_compiler_modules_library`, since they do
not depend on the inputs. Some calculations relative to `-resource-dir`
depend on the Swift compiler path, which cannot be moved outside the
function.
The calculations outside the function are stored in a cached variable,
which is later used in the function. If the need arise, anyone can
provide a custom value for that variable in their CMake invocation or
cache files adapted for their specific case and override the
automatically calculated default.
I also rewrote a couple of `set(list ${list} …)` into `list(APPEND
list …)`.
This should be NFC for the Swift CI, because no value of
`SWIFT_COMPILER_SOURCES_SDK_FLAGS` is provided, and the default should
be the same value as before.
If one is building a LLVM unified build, with Swift as an external
project, SwiftCompilerSources can compile before the `.td` files that
generate Clang headers are finished, which will make the compilation
fail to find some files (the `.inc` files derived from those `.td`).
Make the library that uses the header depend on `clang-tablegen-targets`
to ensure those are done before the library is tried to be used.
This is not a problem in the normal `build-script` builds because in
those cases, the LLVM/Clang headers are build way before Swift is
started to be build.
ASTGen always builds with the host Swift compiler, without requiring
bootstrapping, and is enabled in more places. Move the regex literal
parsing logic there so it is enabled in more host environments, and
makes use of CMake's Swift support. Enable all of the regex literal
tests when ASTGen is built, to ensure everything is working.
Remove the "AST" and "Parse" Swift modules from SwiftCompilerSources,
because they are no longer needed.
Introduce two modes of bridging:
* inline mode: this is basically how it worked so far. Using full C++ interop which allows bridging functions to be inlined.
* pure mode: bridging functions are not inlined but compiled in a cpp file. This allows to reduce the C++ interop requirements to a minimum. No std/llvm/swift headers are imported.
This change requires a major refactoring of bridging sources. The implementation of bridging functions go to two separate files: SILBridgingImpl.h and OptimizerBridgingImpl.h.
Depending on the mode, those files are either included in the corresponding header files (inline mode), or included in the c++ file (pure mode).
The mode can be selected with the BRIDGING_MODE cmake variable. By default it is set to the inline mode (= existing behavior). The pure mode is only selected in certain configurations to work around C++ interop issues:
* In debug builds, to workaround a problem with LLDB's `po` command (rdar://115770255).
* On windows to workaround a build problem.
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.
`add_custom_target_command` has a note in its documentation that ask for
all the `COMMAND` arguments to immediately follow the first argument, or
the function will misbehave.
In the two cases below, the `COMMAND` arguments were after the `OUTPUT`
multivalue, and ended by mistake inside the `OUTPUT` parameter. This
kinda works because CMake will interpolate those back, but causes
problems for dependency resolution, marking many targets as dirty. When
one of those targets is dependent by the compiler, this can create
a huge cascade rebuild.
Fix the two cases I found where `add_custom_target_command` was used
incorrectly. This removes cascade rebuilds in my working directory, and
hope it applies to everybody.
There were three different issues going on here, all of these were triggered by https://github.com/apple/swift/pull/61618 which stared including `AST/AnyFunctionRef.h` from the ASTBridging modulemap
- We did not find the clang include dirs because the unified build that build-tooling-libs is using does not import ClangConfig, setting `CLANG_INCLUDE_DIRS` in `swift_common_unified_build_config` fixed this problem.
- Some of the headers in `swift-ast-generated-headers` import generated headers from clang that might not have been created yet. Making `swift-ast-generated-headers` depend on the clang generated headers fixes this problem. This just lowers the dependency because `swiftAST` depends on `swift-ast-generated-headers`
- If a Swift compiler from Xcode is used, the SwiftShims don’t live next to the compiler but in the SDK. Adding the SDKs lib to the include paths fixes this problem
This will allow using Swift headers that include Clang headers from SwiftCompilerSources.
For example, some headers in `swift/Basic` include headers from `clang/Basic`. Currently adding those Swift headers to the modulemap causes a build error.
Refactor the logic so to have a single target to reference the
compatibility libraries for the host, and use that when needed.
The main driver for this change is supporting the cross-compilation of
x86-64 on Apple Silicon.
Supports rdar://90307965
