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.
`:` is not a valid file system character but is used to namespace the
imported targets. This is then used to create the stamp file. Sanitize
the name prior to use as a stamp file name.
"Support Macros in Linux" patches was inconsistent with checking
platforms. Some only checked 'LINUX' but some matches
'LINUX|ANDROID|OPENBSD|FREEBSD'. Although I don't have tested other
platoforms than Linux at all, there's no reason to limit it to Linux.
So use the consistent check to match 'LINUX|ANDROID|OPENBSD|FREEBSD'
swift-compatibility-symbols, swift-def-to-strings-converter,
and swift-serialize-diagnostics don't use any Swift modules. But when
SWIFT_SWIFT_PARSER was enabled, they are linked with swiftCore. But
these binaries can be executed before the runtime is being built.
We need to stop them linking with swiftCore.
In Linux. Instead of setting temporary "fallback" RUNPATH, Set
LD_LIBRARY_PATH to builder's runtime when building standard library.
So we don't need to strip the temporary RUNPATH when installing.
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.
