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
- 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
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.
The situations where we use this action, e.g. explicit module building and
generating prebuilt module cache, don't need synchronization. We should avoid
using lock files for them.
rdar://65005528
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`.
Previously we may have silently bailed if a private
module interface path was specified, but the
frontend action didn't support it. Instead, make
sure we enforce the same restrictions that we
enforce for public module interfaces.
Move the playground and debugger transforms out
of the Frontend and into `performTypeChecking`, as
we'd want them to be applied if
`performTypeChecking` was called lazily.
Implement a new "fast" dependency scanning option,
`-scan-dependencies`, in the Swift frontend that determines all
of the source file and module dependencies for a given set of
Swift sources. It covers four forms of modules:
1) Swift (serialized) module files, by reading the module header
2) Swift interface files, by parsing the source code to find imports
3) Swift source modules, by parsing the source code to find imports
4) Clang modules, using Clang's fast dependency scanning tool
A single `-scan-dependencies` operation maps out the full
dependency graph for the given Swift source files, including all
of the Swift and Clang modules that may need to be built, such
that all of the work can be scheduled up front by the Swift
driver or any other build system that understands this
option. The dependency graph is emitted as JSON, which can be
consumed by these other tools.
Check whether the user has provided a valid
identifier when parsing the options. Also make
ImplicitImportModuleNames a private member of
FrontendOptions to prevent mutation after being
parsed.
Several tests related to indexing system modules were taking a considerable
amount of time (100+ seconds in the worst case) indexing the standard library.
This adds a frontend option to skip it and updates those tests to pass it.
Compatibility header may #import bridging header if specified with -import-underlying-module.
How these two headers are relative to each other is subject to project setting. To accommodate
this, we should allow users to specify bridging header directory for header generating purposes.
rdar://59110975
When enabled at the driver level, the frontends will inherit the flag. For each frontend that recieves this option, all primaries will have their reference dependencies validated.
Remove the option to switch off nested types tables. In a world where
re-entrant direct lookup will cause deserialization to fail (or worse),
disabling these tables will only lead to further instability in the
compiler.
Rather than only emitting the target triple, provide additional
information about that particular target, including the module triple
(i.e., what file names will be used for Swift modules for that
triple), the runtime compatibility version if there is one, and
whether linking with rpaths is required for the standard library and
other libraries shipped with Swift. Encode this as JSON so we can
extend it in the future. For now, it looks like this:
```
{
"target": {
"triple": "arm64-apple-ios12.0",
"moduleTriple": "arm64-apple-ios",
"swiftRuntimeCompatibilityVersion": "5.0",
"librariesRequireRPath": true
}
}
```
Which you can deserialize into a TargetInfo instance as defined below:
```
struct Target: Codable {
/// The target triple.
var triple: String
/// The triple used for module file names.
var moduleTriple: String
/// If this platform provides the Swift runtime, the Swift language
version
/// with which that runtime is compatible.
var swiftRuntimeCompatibilityVersion: String?
/// Whether linking against the Swift libraries requires the use of
rpaths.
var librariesRequireRPath: Bool
}
struct TargetInfo: Codable {
var target: Target
}
```
Implements rdar://problem/47095159.
Add a -print-target-triple command line option to the Swift frontend
and driver to allow other tools (e.g., SwiftPM) to query the host
triple as it is understood by the Swift compiler. This follows the
precedent set by Clang. Implements rdar://problem/57434967.
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.
For now, until we figure out the right way to present
-experimental-skip-non-inlinable-function-bodies, make
-tbd-is-installapi imply that, for testing.
We generate .swiftsourceinfo for stdlib in the build directory because ABI checker
could issue diagnostics to the stdlib source. However, this may also change other
diagnostic tests. Both Brent and Jordan have raised concern about this. After
adding this flag, other diagnostic tests could ignore .swiftsourceinfo files even
though when they are present so our tests will reflect what most users experience
when sources for stdlib are unavailable.
This flag, currently staged in as `-experimental-skip-non-inlinable-function-bodies`, will cause the typechecker to skip typechecking bodies of functions that will not be serialized in the resulting `.swiftmodule`. This patch also includes a SIL verifier that ensures that we don’t accidentally include a body that we should have skipped.
There is still some work left to make sure the emitted .swiftmodule is exactly the same as what’s emitted without the flag, which is what’s causing the benchmark noise above. I’ll be committing follow-up patches to address those, but for now I’m going to land the implementation behind a flag.
Leave the old flag in as an alias to the new flag, for transition
purposes. Also go ahead and remove the long-deprecated and unused
`emit-interface-path`.
Part of rdar://49359734
When compiling SwiftOnoneSupport, issue errors for missing functions which are expected in the module.
This ensures ABI compatibility.
rdar://problem/48924409
...and remove the option. This is ~technically~ CLI-breaking because
Swift 5 shipped this as a hidden driver option, but it wouldn't have
/done/ anything in Swift 5, so I think it's okay to remove.
Note that if a parseable interface (.swiftinterface) and a binary
interface (.swiftmodule) are both present, the binary one will still
be preferred. This just /allows/ parseable interfaces to be used.
rdar://problem/36885834
Makes it easier to test the caching behavior, and may also be useful
for "prebuilding" swiftinterfaces in the future, or having the Driver
kick off a bunch of separate builds as proper tasks.
By default, the frontend tries to figure out if the built module is
likely to be distributed in some way, and uses that to decide whether
to include options that help with debugging (such as local search
paths). There's long been a -serialize-debugging-options that forces
those options to be included even when it looks like a framework is
being built, but the opposite has been absent until now.
Note that both of these options are still /frontend/ options, not
driver options, which means they could still change in the future.
(I'd really like to get to a point where debugging doesn't need to
sniff these options out from the module this way, but there are some
complications we'd need to work out. Swift 1 expediency coming back to
cause trouble again.)
rdar://problem/37954803
