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.
This change removes the -emit-cxx-header option, and adds a new -emit-clang-header-path option instead. It's aliased to -emit-objc-header-path for now, but in the future, -emit-objc-header-path will alias to it. After this change Swift can start emitting a single header file that can be expose declarations to C, Objective-C, or C++. For now C++ interface is generated (for all public decls) only when -enable-cxx-interop flag is passed, but that behavior will change once attribute is supported.
This additional supplement output should capture semantic info the compiler has
captured while building a Swift module. Similar to the source info file, the content of
the semantic info file should only be consumed by local tooling written in Swift.
The Swift driver is passing the optimization record file path via the supplementals output, instead of the flag, on certain circumstances.
Enhance the frontend to check supplemental outputs otherwise the record file will not get emitted when using the new swift driver.
We have implemented a libSwiftDriver-based tool to generate prebuilt module cache for
entire SDKs. Anchored on the same infrastructure, we could also generate ABI baselines
for entire SDKs.
These new options mirror -o and -output-filelist and are used instead
of those options to supply the output file path(s) to record in the
index store. This is intended to allow sharing index data across
builds in separate directories that are otherwise equivalent as far
as the index data is concered (e.g. an ASAN build and a non-ASAN build)
by supplying the same -index-unit-output-path for both.
Resolves rdar://problem/74816412
When symbols are moved to this module, this module declares them as HIDE
for the OS versions prior to when the move happened. On the other hand, the
original module should declare ADD them for these OS versions. An executable
can choose the right library to link against depending on the deployment target.
This is a walk-around that linker directives cannot specify other install
name per symbol, we should eventually remove this.
Frontend outputs source-as-compiled, and source-ranges file with function body ranges and ranges that were unparsed in secondaries.
Driver computes diffs for each source file. If diffs are in function bodies, only recompiles that one file. Else if diffs are in what another file did not parse, then the other file need not be rebuilt.
We already have something called "module interfaces" -- it's the
generated interface view that you can see in Xcode, the interface
that's meant for developers using a library. Of course, that's also a
textual format. To reduce confusion, rename the new module stability
feature to "parseable [module] interfaces".
...but don't hook it up to anything yet.
This is the very very start of the module stability / textual
interfaces feature described at
https://forums.swift.org/t/plan-for-module-stability/14551/
For now I've just made it a frontend option (not a driver option),
which is good enough for testing.
This means moving the output path into SupplementaryOutputPaths, and
using the same sort of diagnostic dispatching that serialized
diagnostics use. This is part of what's needed to run the migrator
in batch mode.
