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.
PublicCMOSymbols stores symbols which are made public by cross-module-optimizations.
Those symbols are primarily stored in SILModule and eventually used by TBD generation and validation.
This patch fixes the call to get the datalayout from the clang module.
Clang no longer holds onto the DataLayout object, so we have to do that
if we want to keep it around. Rather than instanciating it early, we can
just hold onto the string description, which clang does keep around, and
only construct the actual DataLayout once we need it.
Add a new swift-frontend driver option that extract APIs in the swift
module and print in JSON format. This is to allow tooling to understand
and process swift APIs without the need to be a swift compiler or
understand swift module/AST.
Add a request that leverages the TBDGenVisitor to
produce a mapping from a mangled symbol name to
the SIL or IR entity that emits it. This will be
used to enable lazy compilation where only a
specific set of symbols need to be emitted.
Refactor `TBDGenVisitor` to accept a callback for
when it discovers a symbol, and split off public
symbol gathering into `PublicSymbolsRequest` such
that we don't need to unnecessarily also build a
TBD file which we immediately throw away.
A request is intended to be a pure function of its inputs. That function could, in theory, fail. In practice, there were basically no requests taking advantage of this ability - the few that were using it to explicitly detect cycles can just return reasonable defaults instead of forwarding the error on up the stack.
This is because cycles are checked by *the Evaluator*, and are unwound by the Evaluator.
Therefore, restore the idea that the evaluate functions are themselves pure, but keep the idea that *evaluation* of those requests may fail. This model enables the best of both worlds: we not only keep the evaluator flexible enough to handle future use cases like cancellation and diagnostic invalidation, but also request-based dependencies using the values computed at the evaluation points. These aforementioned use cases would use the llvm::Expected interface and the regular evaluation-point interface respectively.
