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
`sed` is not available on all platforms, we cannot depend on that to
rewrite the module map. As a temporary stop gap, write the file
statically and generate it at build time. Eventually, this could be
replaced with a tool or CMake based text processing to generate the
content. This repairs part of the build for Windows with bootstrapping.
The bootstrapping stages were missing dependencies on the Concurrency
and Swift 5.6 backdeployment compatibility libraries resulting in
failing builds.
When using a unified LLVM + Swift build (using `LLVM_EXTERNAL_PROJECTS=swift`),
`CMAKE_SOURCE_DIR` is `llvm-project/llvm`, and appending `include/swift` to that directory doesn’t result in the directory that contains Swift’s header files.
Instead, look up the header files relative to `CMAKE_CURRENT_SOURCE_DIR`.
When using a unified LLVM + Swift build (using `LLVM_EXTERNAL_PROJECTS=swift`), swift is installed into `build_dir/tools/swift`. Thus, we also need to find the generated headers inside the `tools/swift/include` directory and not at the top-level `build_dir/include` directory.
To use new C++ interop features in SwiftCompilerSources, we need a very recent Swift compiler when building with host tools.
This does not affect non-HOSTTOOLS builds.
To use _RegexParser from SwiftSyntax.
* Create 'libswiftCompilerModules_SwiftSyntax.a' which is a subset of
'libswiftCompilerModules.a'
* Link 'lib_InternalSwiftSyntaxParser' to
'libswiftCompilerModules_SwiftSyntax.a'
* Factor out swift runtime linking logic in CMake so that dynamic
libraries can link to Swift runtime, in addition to executables
* Link 'lib_InternalSwiftSyntaxParser' to swift runtime
Some code in SwiftCompilerSources, especially the parts that use C++ interop, triggers bugs in older versions of the Swift compiler. To make sure that `HOSTTOOLS` builds don't produce obscure compiler errors or crashes, let's require a relatively new Swift compiler for `HOSTTOOLS` build.
