This mechanism allows the compiler to use a backup interface file to build into a binary module when
a corresponding interface file from the SDK is failing for whatever reasons. This mechansim should be entirely opaque
to end users except several diagnostic messages communicating backup interfaces are used.
Part of rdar://77676064
If the `-static` option is specified, store that in the generated
swiftmodule file. When de-serializing, recover this information in the
representative SILModule.
This will be used for code generation on Windows. It is the missing
piece to allow static linking to function properly. It additionally
opens the path to additional optimization on ELF-ish targets - GOT, PLT
references can be avoided when the linked module is known to be static.
Co-authored by: Saleem Abdulrasool <compnerd@compnerd.org>
This allows library authors to pass down a project version number so that library users can conditionally
import that library based on the available version in the search paths.
Needed for rdar://73992299
Introduce a new compiler flag `-module-abi-name <name>` that uses the
given name as the ABI name for the module (rather than the module's
name in source code). The ABI name impacts name mangling and metadata.
In the legacy driver, these flags will merely be propagated to the
frontends to indicate that they should disable serialization of
incremental information in swift module files.
In the new driver, these flags control whether the Swift driver performs
an incremental build that is aware of metadata embedded in the module.
Kudos to David for coming up with our new marketing name: Incremental
Imports.
rdar://74363450
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
This option allows the compiler to retry opening an input file if the previous
opening returns an error of bad file descriptor. Swift-driver will set this
argument in certain circumstances to walk-around such error.
rdar://73157185
This frontend flag can be used as an alternative to
-experimental-skip-non-inlinable-function-bodies that doesn’t skip
functions defining nested types. We want to keep these types as they are
used by LLDB. Other functions ares safe to skip parsing and
type-checking.
rdar://71130519
Adds a new frontend option
"-experimental-allow-module-with-compiler-errors". If any compilation
errors occur while generating the .swiftmodule, this mode will skip SIL
entirely and only serialize the (likey invalid) AST.
This existence of this option during generation is serialized into the
resulting .swiftmodule. Errors found in deserialization are only allowed
if it is set.
Primarily intended for IDE requests (eg. indexing and code completion)
to ensure robust cross-module results, despite possible errors.
Resolves rdar://69815975
Adds a new flag "-experimental-skip-all-function-bodies" that skips
typechecking and SIL generation for all function bodies (where
possible).
`didSet` functions are still typechecked and have SIL generated as their
body is checked for the `oldValue` parameter, but are not serialized.
Parsing will generally be skipped as well, but this isn't necessarily
the case since other flags (eg. "-verify-syntax-tree") may force delayed
parsing off.
With this option enabled, the dependency scanner gathers all import statements in source files of the main module (non-transitive) and outputs a list of imported modules.
This will be used by build systems and the swift-driver as a way to avoid redundant re-scanning in incremental contexts.
Tying InputFile to this option meant that every input that was not one of the explictly-blessed kinds was modeled as a Swift file.
With the new InputFile that infers file kinds, we no longer need CompilerInvocation::setInputKind
These inputs were previously modeled as Swift files, which would lead to bizarre situations where parts of the pipeline expecting Swift inputs actually wound up parsing Objective-C.
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.
