Extricate cmark from the unified build system. This is preparatory work
to support building CMark GFM with dynamic linkage for sharing it across
swift-markdown and the compiler. It also simplifies the build logic for
the unified build.
ClangConfig sets `CLANG_INCLUDE_DIRS` and Swift build system uses that
variable in a couple of places. Without this, several of the include
directories for Clang might not be added to different parts of the
compiler, like when using SwiftSourceSupport files. Before these
changes, headers like `clang/CAS/CASOptions.h` were not being found.
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
Swift-driver PR [1043](https://github.com/apple/swift-driver/pull/1043)
updated the new driver to always emit private swiftinterface files.
This was not carried back to the old driver, so attempting to bootstrap
the toolchain on a system that does not have the new driver fails to
install because we try to install the private swiftinterface on all
Swift targets.
`CMAKE_CXX_FLAGS` are user controlled and should not be touched by the
build system [1]. Use global `add_compile_options` and
`add_compile_definitions` to control the flags for the targets.
[1] https://cmake.org/cmake/help/book/mastering-cmake/
Conditionalise the inclusion of directory paths. If the include
directory is empty, CMake will raise an error. This allows us to disable
larger portions of the Swift build to speed up some of the build tool
configuration phase and prepares for consuming CMark GFM as a CMake
project.
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`.
Conflicts:
- `lib/AST/TypeCheckRequests.cpp` renamed `isMoveOnly` which requires
a static_cast on rebranch because `Optional` is now a `std::optional`.
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.
Conflicts:
- `CMakeLists.txt` caused by the extra `-D` added in rebranch to
reduce the number of deprecation warnings.
- `lib/Frontend/PrintingDiagnosticConsumer.cpp` caused by the removal
of one of the `#if SWIFT_SWIFT_PARSER` on rebranch (probably should
have been done on main).
Because swift_swap_compiler_if_needed updates the compiler ID to
Clang, we need to account for it when deciding to add a dependency on
clang. Otherwise, the sourcekit build could fail due to the clang
executable not having been built there yet.
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
