In the fast dependency scanner, depending on whether a module intrface was found via the import search path or framework search path, encode into the dependency graph Swift module details, whether a given module is a framework.
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.
Instead of replacing an interface file with its up-to-date compile module,
the dep-scanner should report potentially up-to-date module candidates either adjacent to
the interface file or in the prebuilt module cache. swift-driver should later pass down
these candidates to -compile-module-from-interface invocation and the front-end job
will check if one of the candidates is ready to use. The front-end job then either emits a forwarding
module to an up-to-date candidate or a binary module.
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.
A couple of clients are iterating over the result,
so switch to a vector to ensure we don't
accidentally introduce any non-determinism.
(cherry picked from commit 56929fdaaa)
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`.
(cherry picked from commit c0a2ea7d0e)
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`.
(cherry picked from commit 0e97ecedd6)
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.
For the explicit module mode, swift-driver uses -compile-module-from-interface to
generate modules from interfaces found by the dependency scanner. However, we don't
need to build the binary module if up-to-date modules are available, either adjacent
to the interface file or in the prebuilt module cache directory. This patch teaches
dependencies scanner to report these ready-to-use binary modules.
