getAll deserializes all SIL (except for globals). This enables us to iterate
over the SILModules once instead of once for first SILFunctions, then VTables,
then WitnessTables which is just inefficient.
Swift SVN r14176
We add two records in sil_block to specify a witness table record and a method
entry record. Out of the four entry types, only "Method" is handled in this
commit.
Two records are also added to sil_index_block to search for a specific witness
table given a unique identifier. The interface lookupWitnessTable is not
implemented yet.
Right now, we serialize a witness table only when sil-serialize-all is on and
deserialize all witness tables in the module when sil-link-all is on.
rdar://15722175
Swift SVN r13000
In general, this forces SILGen and IRGen code that's grabbing
a declaration to state whether it's doing so to define it.
Change SIL serialization to serialize the linkage of functions
and global variables, which means also serializing declarations.
Change the deserializer to use this stored linkage, even when
only deserializing a declaration, and to call a callback to
inform the client that it has deserialized a new entity.
Take advantage of that callback in the linking pass to alter
the deserialized linkage as appropriate for the fact that we
imported the declaration. This computation should really take
advantage of the relationship between modules, but currently
it does not.
Swift SVN r12090
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
Part of the FileUnit restructuring. A serialized module is now represented as
a TranslationUnit containing a single SerializedASTFile.
As part of this change, the FileUnit interface has been made virtual, rather
than switching on the Kind in every accessor. We think the operations
performed on files are sufficiently high-level that this shouldn't affect us.
A nice side effect of all this is that we now properly model the visibility
of modules imported into source files. Previously, we would always consider
the top-level imports of all files within a target, whether re-exported or
not.
We may still end up wanting to distinguish properties of a complete Swift
module file from a partial AST file, but we can do that within
SerializedModuleLoader.
Swift SVN r10832
We add two records in sil_block to specify a Vtable and its entry list. Two
records are also added in sil_index_block for mapping from name to ID and
from ID to bit offset.
Two functions are added to SerializedSILLoader: to look up a specific VTable
given the class name or to deserialize all VTables in all SILModules. The latter
is mostly used for testing.
We serialize a VTable if the class is fragile and deserialize it via
SerializedSILLoader::lookupVTable.
Swift SVN r9746
Add command line argument -sil-link-all and -sil-serialize-all for testing
purpose.
Do not create new SILFunction for de-serialized SIL, instead update the
existing declaration with the de-serialized SILFunction.
Add testing case to cover partial_apply.
Swift SVN r8410
SerializedSILLoader to hold a list of SIL deserializers.
Also add an intial implementation of a linking pass that is run right after
SILGen to link the declaration of SILFunction to the actual definition in
the serialized module.
We add two blocks to the serialized module: a sil index block that
maps identifier to a function ID and also holds a list of function offsets,
and a sil block for the actual SILFunctions. We can probably use subblock
instead of two top-level blocks.
The serialization/de-serialization of the function hash table and the function
offsets are implemented. But we are missing handling of types (see FIXME in
the code).
ModuleFile::Serialized is made public to be used by SIL deserializer, as well
as ModuleFile::getType.
The SIL deserializer holds a pointer to the ModuleFile, it gets the sil cursor
and the sil index cursor from the ModuleFile. The other option is for SIL
deserializer to find the start of the two sil blocks within itself, thus having
less coupling with ModuleFile.
No testing case yet because we are missing handling of types.
Swift SVN r8206
