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`.
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
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.
