This scanning mode allows swift-driver to query module dependencies in a batch
and in a more granular way. In short term, it could help solve a problem that
clang module dependencies may vary if target triple changes. In a longer term,
we could break a holistic dependencies graph into smaller pieces for better caching
and reusing.
This change doesn't include the implementation of using the specified scanner
arguments to set up Clang dependencies scanner. It will come in later commits.
For the issue mentioned in rdar://67079780, swift-driver needs to run clang dependencies
scanner multiple times with different target triples for a Swift target. This patch adds
a new scanning action to generate the JSON file for a given clang module to accommodate
this requirement.
Resolves: rdar://problem/67269210
Based on measurements, it seemed to save about 0.2 ms - 0.4 ms for a module
with a large number of imports from the SDK. That's insignificant compared to
the compile time for a typical module, which usually takes somewhere between
a few seconds and a few minutes.
- deduplicate the logic to compute the resource folder
- install headers and module files in shared and static resource folders
- forward -static flag when calling swiftc with -print-target-info
Seperating out TBD file generation uncovered a bug
in the frontend where we could fail to notice that
we emitted an error during the end-of-pipeline
actions and returned a zero exit code. Tweak the
logic to detect this case.
We need to traverse the module dependency graph and track which modules expose
which other modules' ABIs, while making sure that we don't hit a loop while
trawling through Clang (sub)modules.
Fixes rdar://64993153.
This flag no longer does anything now that the unified statistics
reporting infrastructure exists. It is better to use
-driver-time-compilation to see a bird's eye view of timing statistics
for frontend jobs, and -stats-output-dir to see a down-and-dirty view of
everything including performance counters.
With an inverted pipeline, IRGen needs to be able
to compute the linker directives itself, so sink
it down such that it can be computed by the
`IRGenDescriptor`.
Instead of taking an out parameter, have it return
the set directly. Also coalesce the two overloads
into a single overload that takes a
`TBDGenDescriptor`.
The driver and any other client that attempts to properly link Swift
code need to know which compatibility libraries should be linked on a
per-target basis. Vend that information as part of -print-target-info.
Expand the FrontendOptions to allow the enabling
of the dependency tracker for non-system
dependencies, and switch the previous clients of
`createDependencyTracker` over to using this
option. This ensures that the dependency tracker
is now set only during `CompilerInstance::setup`.
The use of `SWIFT_DEFER` previously meant that we
may return `false` from `performCompile` even if
an error was produced from
`performEndOfPipelineActions`.
To remedy this, introduce a lambda that both calls
`performEndOfPipelineActions`, and checks to see
if there was an error. Then, enforce that all exit
paths call this lambda.
Move both the loaded module trace output and
"additional whole module outputs" to the end of
the pipeline, ensuring to preserve the behaviour
where we skip them if we encountered an error.
There's no reason clients need to be able to access this data directly.
It obscures where module loading is actually happening, and makes it too
easy to accidentally register a module with the wrong identifier in the
context.
Hide the registration operations behind opaque accessors.
We were not using the primary benefits of an intrusive list, namely the
ability to insert or remove from the middle of the list, so let's switch
to a plain vector. This also avoids linked-list pointer chasing.
Most clients were only using it to populate the
main module with files, which is now done by
`getMainModule`. Instead, they can now just rely
on parsing happening lazily.
Move into `performEndOfPipelineActions`, and move
the call up a bit in `performCompile` to make sure
it gets called even for a parse-only invocation.
Unfortunately this requires carving out an
exception for `-emit-imported-modules`, which can
load modules.
Lift the `DisablePoundIfEvaluation` parsing option
into `LangOptions` to subsume the need for the
`EvaluateConditionals` parameter, and sink the
computation of `CanDelayBodies` down into
`createSourceFileForMainModule`.
Rather than trying to continue the compilation
with an empty main module, let's bail out early if
we expect an implicit stdlib import and fail to
load in the stdlib.
