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.
De-duplicate TypeCheckingFlags, TypeChecker's Options, and the TypeChecker-Oriented FrontendOptions into a dedicated TypeCheckerOptions type. This moves a bunch of configuration state out of the type checker and into the ASTContext where it belongs.
✔ More informative error messages in case of crashes.
✔ Handling and documenting different cases.
✔ Test cases for different cases.
✔ Make SDKDependencies.swift pass again.
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.
After setting up the .swiftsourceinfo file, this patch starts to actually serialize
and de-serialize source locations for declaration. The binary format of .swiftsourceinfo
currently contains these three records:
BasicDeclLocs: a hash table mapping from a USR ID to a list of basic source locations. The USR id
could be retrieved from the following DeclUSRs record using an actual decl USR. The basic source locations
include a file ID and the results from Decl::getLoc(), ValueDecl::getNameLoc(), Decl::getStartLoc() and Decl::getEndLoc().
The file ID could be used to retrieve the actual file name from the following SourceFilePaths record.
Each location is encoded as a line:column pair.
DeclUSRS: a hash table mapping from USR to a USR ID used by location records.
SourceFilePaths: a hash table mapping from a file ID to actual file name.
BasicDeclLocs should be sufficient for most diagnostic cases. If additional source locations
are needed, we could always add new source location records without breaking the backward compatibility.
When de-serializing the source location from a module-imported decl, we calculate its USR, retrieve the USR ID
from the DeclUSRS record, and use the USR ID to look up the basic location list in the BasicDeclLocs record.
For more details about .swiftsourceinfo file: https://forums.swift.org/t/proposal-emitting-source-information-file-during-compilation
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.
Like the last commit, SourceFile is used a lot by Parse and Sema, but
less so by the ClangImporter and (de)Serialization. Split it out to
cut down on recompilation times when something changes.
This commit does /not/ split the implementation of SourceFile out of
Module.cpp, which is where most of it lives. That might also be a
reasonable change, but the reason I was reluctant to is because a
number of SourceFile members correspond to the entry points in
ModuleDecl. Someone else can pick this up later if they decide it's a
good idea.
No functionality change.
Most of AST, Parse, and Sema deal with FileUnits regularly, but SIL
and IRGen certainly don't. Split FileUnit out into its own header to
cut down on recompilation times when something changes.
No functionality change.
Add a new type of diagnostic transaction, CompoundDiagnosticTransaction.
The first diagnostic emitted inside the transaction will become the parent of the subsequent notes.
DiagnosticConsumers may opt in to consuming these child notes alongside the parent
diagnostic, or they can continue to consider them seperately.
Moved PrintingDiagnosticConsumer and a couple of diagnostics to the new
system as a proof of concept.
DelayedParsingCallbacks only had one implementation, for code
completion, which is only used to determine which bodies to skip and
which to delay. Inline that logic into the parser's delay logic and
remove DelayedParsingCallbacks entirely.
ABI checker imports Swift frameworks by using Swift interfaces for various
reasons. The existing way of controlling preferred importing mechanism is by
setting an environment variable (SWIFT_FORCE_MODULE_LOADING), which may lead
to performance issues because the stdlib could also be loaded in this way.
This patch adds a new front-end option to specify module names for
which we prefer to importing via Swift interface. The option currently is only
accessible via swift-api-digester.
rdar://54559888
We want SILGen and IRGen to also be able to trigger delayed parsing if
necessary, so tweak things here a bit. For now this is NFC, since name
lookup triggers delayed parsing of all types and extensions the first
time a name lookup is performed -- but that is about to change.
There are still cases (a module with a type that's the same name as the
module) where we cannot fully qualify all types. In those cases, allow
them to remain unqualified with a flag, `-Xfrontend
-preserve-types-as-written-in-module-interface`.
This mode is supposed to get all its configuration information from
the switftinterface being read in, but that means that the ASTContext
and ClangImporter that get created by default may not be a sensible
configuration (for example, a mismatched target and SDK, which Clang
emits a warning about). Avoid this by just not creating the ASTContext
if it's already been determined that the frontend is building a module
from a parseable interface.
swift-tools-version as used by SwiftPM is an actual, parsed field with
semantic meaning. swift-compiler-version as used when generating
module interfaces is just to record what version of the compiler
generated the interface. They shouldn't have the same name.
Previously, we wouldn't pass this flag to sub-invocations, which means
that if we had to fall back and recompile a transitive import, we
wouldn't get a remark.
rdar://50729662
Keep track of information that led the module interface loader to reject loading a compiled module, if it needed to fall back to compiling an interface.
rdar://47792754
form SerializedModuleLoader into its own ModuleLoader class. (NFC-ish)
This gives better control over the order in which the various module
load mechanisms are applied.
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
