Fully support make-style `.d` dependencies file output by making
following improvements:
* All correct dependency file render when cache hit for a different
output file location. The dependency file should list the correct
output path, not the stale output path for the initial compilation
* When enable a path prefix mapper to canonicalize the path, the
dependency file should render the input file correctly as the input
file path on disk.
rdar://132250067
Separate swift-syntax libs for the compiler and for the library plugins.
Compiler communicates with library plugins using serialized messages
just like executable plugins.
* `lib/swift/host/compiler/lib_Compiler*.dylib`(`lib/CompilerSwiftSyntax`):
swift-syntax libraries for compiler. Library evolution is disabled.
* Compiler (`ASTGen` and `swiftIDEUtilsBridging`) only depends on
`lib/swift/host/compiler` libraries.
* `SwiftInProcPluginServer`: In-process plugin server shared library.
This has one `swift_inproc_plugins_handle_message` entry point that
receives a message and return the response.
* In the compiler
* Add `-in-process-plugin-server-path` front-end option, which specifies
the `SwiftInProcPluginServer` shared library path.
* Remove `LoadedLibraryPlugin`, because all library plugins are managed
by `SwiftInProcPluginServer`
* Introduce abstract `CompilerPlugin` class that has 2 subclasses:
* `LoadedExecutablePlugin` existing class that represents an
executable plugin
* `InProcessPlugins` wraps `dlopen`ed `SwiftInProcPluginServer`
* Unified the code path in `TypeCheckMacros.cpp` and `ASTGen`, the
difference between executable plugins and library plugins are now
abstracted by `CompilerPlugin`
Update swift cache key computation mechanism from one cache key per
output, to one cache key per primary input file (for all outputs that
associated with that input).
The new schema allows fewer cache lookups while still preserving most of
the flexibility for batch mode and incremental mode.
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.
Add a CachedDiagnosticsProcessor that is a DiagConsumer can capture all
the diagnostics during a compilation, serialized them into CAS with a
format that can be replayed without re-compiling.
Teach swift how to serialize its input into CAS to create a cache key
for compiler outputs. To compute the cache key for the output, it first
needs to compute a base-key for the compiler invocation. The base key is
computed from: swift compiler version and the command-line arguments for
the invocation.
Each compiler output from swift will gets its own key. The key for the
output is computed from: the base key for the compiler invocation + the
primary input for the output + the output type.
Push the top level logic for writing out swiftmodules and associated files into the frontend library which has access to all the necessary dependencies.
These libraries formed a strongly connected component in the CMake build graph. The weakest link I could find was from IDE to FrontendTool and Frontend, which was necessitated by the `CompileInstance` class (https://github.com/apple/swift/pull/40645). I moved a few files out of IDE into a new IDETools library to break the cycle.
The relationship between the code in these two libraries was fundamentally circular, indicating that they should not have been split. With other changes that I'm making to remove circular dependencies from the CMake build graph I eventually uncovered that these two libraries were required to link each other circularly, but that had been hidden by other cycles in the build graph previously.
Otherwise we set it on all targets/languages in a subdirectory (I forgot if it
propagates up). Regardless, this type of viral stuff is something we want to
move away from since it creates a code that is a "forall" piece of code rather
than a piece of code that only effects a single target.
I also conditionalized the actual definitions being added on the compiled file's
language being C,CXX,OBJC,OBJCXX since as we add Swift sources to the host side
of the compiler, we will not want these flags to propagate to Swift sources.
Create a new diagnostics serialization library, splitting out of
swiftAST to reduce the overheads for building the tooling for
cross-compiling the toolchain. This should reduce the build time for
swift-serialize-diagnostics to enable cross-compilation.
Move the source files from ParserSIL into the SIL library and remove the
ParserSIL library. ParsersSIL doesn't need to be its own library and this change will
simplify our builds.
A follow-up PR adds a flag to control an inline namespace that allows
symbols in libDemangling to be distinguished between the runtime and
the compiler. These dependencies ensure that the flag is plumbed
through for inclusions of Demangling headers that aren't already
covered by existing `target_link_libraries`.
The DependencyVerifier is a DiagnosticVerifier-alike utility that takes annotations in user code and transforms them into a set of expectations. Those expectations are met by corresponding "obligations", which are constructed by reading the contents of the referenced name tracker associated with the source files for each of the primary inputs to a frontend job. The verifier will then pair off expectations and obligations, and ensure that any remaining unpaired obligations are diagnosed as failures.
This tool will not only ensure the correctness of the referenced name tracker's output, it will provide us with tests that ensure its output is stable, and give us the confidence to replace it with an evaluator-based tracking scheme in the future.
Resolves rdar://59773883
Rather than registering individual IRGen passes
when we want to execute them, store function
pointers to all the pass constructors on the
ASTContext. This will make it easier to requestify
the execution of pass pipelines.
A ‘forwarding module’ is a YAML file that’s meant to stand in for a .swiftmodule file and provide an up-to-date description of its dependencies, always using modification times.
When a ‘prebuilt module’ is first loaded, we verify that it’s up-to-date by hashing all of its dependencies. Since this is orders of magnitude slower than reading mtimes, we’ll install a `forwarding module` containing the mtimes of the now-validated dependencies.
This is a follow up to the discussion on #22740 to switch the host
libraries to use the `target_link_libraries` rather than the
`LINK_LIBRARIES` special handling. This allows the dependency to be
properly tracked by CMake and allows us to use the more modern syntax.
This reverts commit 121f5b64be.
Sorry to revert this again. This commit makes some pretty big changes. After
messing with the merge-conflict created by this internally, I did not feel
comfortable landing this now. I talked with Saleem and he agreed with me that
this was the right thing to do.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
