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.
`Package.swift` in the build directory and symlinking Sources directory
wasn't great for source control and break points. Since C modules doesn't
need the generated headers at this point, make `Package.swift` static
again with a symlink to the string processing source directory.
Previously, it used ${CMAKE_CURRENT_BINARY_DIR} as the package
directory. However, since that directory contains all build artifacts so
opening it in Xcode shows those unnecessary files.
Intead of using ${CMAKE_CURRENT_BINARY_DIR}, create its own directory in
the root build directory.
Since libstdc++ doesn't come with a Clang modulemap, Swift provides its own modulemap for libstdc++. This change makes the modulemap available while building SwiftCompilerSources.
This fixes:
* An issue where the diagnostic messages were leaked
* Diagnose at correct position inside the regex literal
To do this:
* Introduce 'Parse' SwiftCompiler module that is a bridging layer
between '_CompilerRegexParser' and C++ libParse
* Move libswiftParseRegexLiteral and libswiftLexRegexLiteral to 'Parse'
Also this change makes 'SwiftCompilerSources/Package.swift' be configured
by CMake so it can actually be built with 'swift-build'.
rdar://92187284
After the rename of the `enable-cxx-interop` option to `enable-experimental-cxx-interop` it was no longer possible to build with installed tools.
This change re-introduces the `enable-cxx-interop` option for backward compatibility
There was only an ordering dependency between modules but not a file dependency.
This caused missing re-compiles of depending modules in incremental builds.
Xcode does not compile libraries that contain only object files; it just skips them completely, not even mentioning them in the logs. Therefore, it fails to create the static library that would contain all SwiftCompilerSources object files. As a workaround, we add a dummy script phase to the target, to force that it gets compiled.
