This directory should be excluded during installation since the content is only
used for local development. swiftsourceinfo file is currently emitted to this directory.
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
- No need to hash input values first
- Pass many values to a single hash_combine to save on intermediates
- Use hash_combine_range instead of a loop of hash_combines
No functionality change.
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.
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.
Use the delayed parsing of function bodies for source imports, and
switch source imports over to lazy type checking. There's no point in
doing a full type check for them.
Lazy parsing for the members of nominal types and extensions depends
only on information already present in
`IterableDeclContext`. Eliminate the use of PersistentParserState as
an intermediary and have the member-parsing request construct a new
`Parser` instance itself to handle parsing. Make this possible even
for ill-formed nominal types/extensions to simplify the code path.
Eliminate `LazyMemberParser` and all of its uses, because it was only
present for lazy member parsing, which no longer needs it.
Ensure that lazy parsing of the members of nominal type definitions
and extensions is handled through a request. Most of the effort here
is in establishing a new request zone for parser requests.
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
The clang importer has to deal with two virtual file systems, one coming
from clang, and one coming from swift. Currently, if both are set, we
emit a diagnostic that we'll pick the swift one.
This commit changes that, by merging the two virtual file systems. The
motivation for this change is the reproducer infrastructure in LLDB,
which adds a third virtual file system to the mix.
(cherry picked from commit 94ef5431ff)
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances in the swift repo.
This refactors DWARFImporter to become a part of ClangImporter, since
it needs access to many of its implementation details anyway. The
DWARFImporterDelegate is just another mechanism for deserializing
Clang ASTs and once we have a Clang AST, the processing is effectively
the same.
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.
Traditionally a serialized binary Swift module (as used in debug info)
can only be imported if all of its Clang dependencies can be imported
*from source*.
- Swift's ClangImporter imports Clang modules by converting Clang AST
types into Swift AST types.
- LLDB knows how to find Clang types in DWARF or other debug info and
can synthesize a Clang AST from that information.
This patch introduces a DWARFImporter delegate that is implemented by
LLDB to connect these two components. With this, a Clang type can be
found (by name) in the debug info and handed over to ClangImporter to
create a Swift type from it. This path has lower fidelity than
importing the Clang modules from source, since it is missing out on
Swiftication annotations and other metadata that is not serialized in
DWARF, but it's invaluable as a fallback mechanism for the debugger
when source code for the Clang modules isn't available or the modules
are otherwise not buildable.
rdar://problem/49233932
This flag adds diagnostic names to the end of their messages, e.g. 'error: cannot convert value of type '[Any]' to specified type '[Int]' [cannot_convert_initializer_value]'. It's intended to be used for debugging purposes when working on the compiler.
IDE functionality needs some internal type checking logics, e.g. checking
whether an extension is applicable to a concrete type. We used to directly
expose an header from sema called IDETypeChecking.h so that IDE functionalities
could invoke these APIs. The goal of the commit and following commits is to
expose evaluator requests instead of directly exposing function entry points from
sema so that we could later move IDETypeChecking.h to libIDE and implement these functions
by internally evaluating these requests.
