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
This necessitated adding a new function to validate a serialized AST, so
that we can get the same information that used to be extracted from the
section header.
For now, we'll continue accepting the wrapped ASTs as well, since we
haven't changed the existing debug info generator.
Swift SVN r12922
We don't currently use this for anything, but if we have the module name
available and easy to access in the bitstream, we can drop the wrapper
around the serialized AST that's put into the binary itself for use by LLDB.
Swift SVN r12921
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
Each loaded file gets added to the main module, rather than being a standalone
separate module. In theory, this will be used to assemble several partial
ASTs into a complete module. In practice, there's still a ways to go...but
this can already round-trip a single module file.
This also factors out the FileUnit-creating part of SerializedModuleLoader,
which should help clients like SourceKit that don't need to search for a
swiftmodule file associated with a particular import.
Swift SVN r10952
Now that everything is done in terms of FileUnits, we don't need LoadedModule
anymore, and now that FileUnits just use virtual dispatch, we don't need to
indirect through ModuleLoader to distinguish them.
This doesn't quite simplify as much as it could, because the next change is
going to combine TranslationUnit and Module.
Swift SVN r10836
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
The goal of this series of commits is to allow the main module to consist
of both source files and AST files, where the AST files represent files
that were already built and don't need to be rebuilt, or of Swift source
files and imported Clang headers that share a module (because they are in
the same target).
Currently modules are divided into different kinds, and that defines how
decls are looked up, how imports are managed, etc. In order to achieve the
goal above, that polymorphism should be pushed down to the individual units
within a module, so that instead of TranslationUnit, BuiltinModule,
SerializedModule, and ClangModule, we have SourceFile, BuiltinUnit,
SerializedFile, and ClangUnit. (Better names welcome.) At that point we can
hopefully collapse TranslationUnit into Module and make Module non-polymorphic.
This commit makes SourceFile the subclass of an abstract FileUnit, and
makes TranslationUnit hold an array of FileUnits instead of SourceFiles.
To demonstrate that this is actually working, the Builtin module has also
been converted to FileUnit: it is now a TranslationUnit containing a single
BuiltinUnit.
Swift SVN r10830
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
Each one has a different kind of lookup cache anyway, and there's no real
reason to have them share storage at the cost of type-safety.
Swift SVN r9242
docs/Resilience.rst describes the notion of a resilience component:
if the current source file is in the same component as a module being
used, it can use fragile access for everything in the other module,
with the assumption that everything in a component will always be
recompiled together.
However, nothing is actually using this today, and the interface we
have is probably not what we'll want in 2.0, when we actually implement
resilience.
Swift SVN r9174
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
getDisplayDecls() was introduced for ":print_module" and works slightly differently, e.g.
it will return the decls from a shadowed clang module, since we want to display them.
Swift SVN r7909
Add tools/lldb-moduleimport-test, which simulates LLDB importing modules
from the __apple_ast section in Mach-O files and use it to regression-test
the new API.
Swift SVN r7709
This is basically the same as doing a :print_decl on every decl in the module,
except that it does not print extensions that come from other modules, and
/does/ print extensions and operators that come from this module.
Does not yet work for Clang modules or the Builtin module.
Swift SVN r7601
In Swift, a module is expected to know which libraries it needs, rather than
having this specified by an external module map. While we haven't quite
designed this yet (frameworks get this for free in Clang, for example),
we can at least provide a simple option for the common case of a module
associated with a single library.
This will probably change in the future, so I left in the more general
deserialization code I was working on before simplifying the use case.
A loaded module can in theory specify any arbitrary frameworks or libraries
as dependencies, not just a single dylib.
Swift SVN r7583
...instead of just those that are re-exported. This will be used for
autolinking (and probably few other places).
As part of this, we get two name changes:
(1) Module::getReexportedModules -> getImportedModules
(2) TranslationUnit::getImportedModules -> getImports
The latter doesn't just get modules-plus-access-paths; it also includes
whether or not the import is re-exported. Mainly, though, it just didn't
seem like a good idea to overload this name when the two functions aren't
really related.
No tests yet, will come with autolinking.
Swift SVN r7487
This separates the concerns of "deserialization the AST structures" from
"reading and accessing a module file".
No functionality change.
Swift SVN r7338
This will be used to resolve properties and method calls on objects with
dynamic-lookup ("id") type. For now, this is tested in swift-ide-test
by using the -dynamic-lookup-completion option and providing a
-code-completion-token value.
Caveats/TODOs:
- As before, since we're using the global method pool, this isn't scoped by
module. We could do a per-module filter, but I don't know if that will
actually buy us much.
- Again, Clang's method pool does not include methods from protocols.
- Lookup by selector name cannot find properties with a customized getter
name. <rdar://problem/14776565>
- The Clang-side method pool is keyed by selector, but Swift wants to look
things up by method name, which maps to the first selector piece, so we
end up having to do a scan of all the selectors in the pool.
Swift SVN r7330
With this, we can now get a list of all class members* available in the
current translation unit, which will be necessary for doing id-style
dynamic lookup (inferring which method you're referring to when the base
type is some magic "dynamic lookup" type).
* Including members of protocols, since a class we don't know about could
have implemented the protocol.
Since there is no code currently using this, I've added a new mode to
swift-ide-test to just dump all class members -- what will eventually
happen when you code complete on a dynamic lookup type. This mode will
go away once the other pieces of id-style lookup are in place.
Swift SVN r7287
...by adding a new callback to ModuleLoader: loadDeclsConformingTo.
This is used only when the type checker doesn't have enough contextual
information to resolve an expression involving a literal, so it's
possible many *LiteralConvertible types will never be loaded.
Deserialization of types with conversion methods is still eager, since
there's no easy hook to tell when they're needed, but the list has been
renamed to refer to any decls that need to be eagerly deserialized, in
case we need it for other purposes in the future.
This probably won't help much in a real program, but it cuts the test
run time by about 5-10% in my build.
Swift SVN r7268
This also makes extension-loading slightly more precise; if asked to
load extensions for some struct Foo, we will load extensions for /every/
struct Foo...but now we won't /also/ load extensions for every /class/ Foo.
Swift SVN r7260
This switches from simple lists of decls to name-based on-disk hash tables,
which allows decls to be loaded lazily when doing simple lookup (but not
code completion, at least not yet).
The on-disk hash table implementation is borrowed from Clang; eventually
it will be pushed down to LLVM's Support library. (Fortunately the
implementation is header-only.)
This breaks a few tests that rely on magic protocols like
IntegerLiteralConvertible, because the type checker won't have seen the
types that conform to those protocols yet. This will be fixed by doing
an additional "hey, modules, got any of these?" lookup.
Swift SVN r7259
Now that we have true serialized modules, the standard library can import
the Builtin module without any special direction (beyond -parse-stdlib),
and anyone can include those modules without special direction.
Swift SVN r6752
This involved threading it through ModuleLoader, as with all the other
module-generic callbacks. I plan to collapse a bit of the chaining, but
unfortunately not that much.
This brings back the CodeCompletion tests.
Swift SVN r6527
Rather than automatically re-exporting or not re-exporting every import in
a TranslationUnit, we'll eventually want to control which imports are local
(most of them) and which imports are shared with eventual module loaders.
It's probably not worth implementing this for TranslationUnit, but
LoadedModule can certainly do something here.
Currently, a LoadedModule is even more permissive than a TranslationUnit:
all imports are re-exported. We can lock down on this once we have a
re-export syntax.
Swift SVN r6523
...and use it for shadowed modules (e.g. the Clang module "Foundation"
referenced by the Swift module "Foundation"), so that we can actually
find "NSString" when building AppKit.
Additionally, record shadowed modules as dependencies, so that they can
be loaded when the adapter module is loaded.
Swift SVN r6522
Same-type requirements aren't tested yet because there's currently no
support for associated types.
This includes an improvement to BCRecordLayout: array elements can be
passed inline, and the static checks that the data count matches the
field count will take this into account.
Swift SVN r5984
This currently does a little dance to handle PolymorphicFunctionTypes.
These are currently implemented by referencing the GenericParamList of
an actual polymorphic function, so they can't be deserialized without
knowing which function they are attached to. To solve this,
PolymorphicFunctionTypes are serialized as regular FunctionTypes. Then,
when a generic function decl is being deserialized, it will rebuild
a PolymorphicFunctionType from the serialized type and its own generic
parameter list.
Requirements on the generic types are coming next.
Swift SVN r5983
This causes the SourceLoader to recursively parse the imported module in standard
library mode, giving it access to the Builtin module.
This is all a terrible hack and should be ripped out with great victory someday, but
until we have binary modules that persist the build setting used to produce the
module, this is the best we can do.
Swift SVN r5847
These are implementing using trailing TUPLE_TYPE_ELT records after the
initial TUPLE_TYPE record. This is the next step towards function decls.
Element initializers are silently ignored for now.
Also, do serialize a record for IdentifierTypes, even though we're not
including the components yet, so that we don't serialize the underlying
type more than once.
Swift SVN r5683
This removes the egregious NAME_HACK records that trailed various named
decls, and replaces them with proper identifier IDs. The identifiers
themselves are serialized into a blob as null-terminated strings, with no
particular optimization (i.e. no substring matching or anything). We can
revisit this format later, but this at least allows identifiers to be
referenced inline within a record, which will be much more convenient for
function parameter patterns (upcoming).
Swift SVN r5638
