As long as we don't create an entity twice, it's actually okay to be
re-entrant. This makes it simpler to deserialize members -- trying to
do so will deserialize the parent instead, which will then initialize
each of the members including the one that was asked for.
Swift SVN r6228
Deserializing a nominal decl often ends up referring to the nominal's type,
so if we're /already/ serializing the type, we should finish that as soon
as we have a decl. Accomplish this by adding a callback that is called
right after a nominal decl is recorded in the module's decl table, so that
the type can be immediately recorded as well.
Swift SVN r6227
These still need to be serialized, because they are one-to-one with the
type's protocol list, but don't actually require any data. Found on
attempting to emit a module for the standard library.
Most of the churn here is moving Interleave.h to a more general STLExtras.h.
Swift SVN r6167
Classes are exactly like structs except that they may have a base class.
However, this type will show up in the inheritance list. That means we
don't actually need to serialize it twice; we can just grab the base class
from the inheritance list.
Swift SVN r6133
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
When loading a module, we now try to load its dependencies as well.
If one of those dependencies can't be loaded, we emit an error message.
Swift SVN r5796
Constructors have their "implicit this" VarDecl specified at creation, but
the context for said VarDecl is the constructor itself. Add a new flag to
allow the deserialization of a VarDecl without setting a DeclContext.
Swift SVN r5747
The main work here is serializing patterns, which are recursive. Unlike
Types, Patterns are not uniqued (in the original AST they contain location
info). Therefore, rather than using cross-referencing IDs, patterns are
serialized as trailing records with an implied hierarchy. Each pattern
record tells you what trailing records to expect. So, for example, the
pattern ((x : Int, y : Int), _ : Int) will give you this serialization:
1. TuplePattern - 2 elements
2. TuplePatternElt
3. TuplePattern - 2 elements
4. TuplePatternElt
5. TypedPattern - Int
6. NamedPattern - x
7. TuplePatternElt
8. TypedPattern - Int
9. NamedPattern - y
10. TuplePatternElt
11. TypedPattern - Int
12. AnyPattern
Functions contain two sets of patterns: "argument" patterns and "body"
patterns, which are different in selector-style declarations. Currently
we always serialize both of these, but it would be easy enough to add a
flag in the FUNC_DECL record to skip one of them if they are the same.
If the function is curried, each set will contain multiple patterns.
These are simply read eagerly as trailing records from the function;
as soon as a non-pattern record is encountered, we know all of the patterns
have been read in.
Swift SVN r5742
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
Unlike Clang, Swift's DeclContexts are not all Decls. However, I believe
each DeclContext that is /serialized/ will be either a decl, a
TranslationUnit, or a FuncExpr for a function with an actual declaration.
This might turn out to be wrong if (a) SIL needs proper DeclContexts for
variables in function bodies, or (b) we need to serialize anonymous
closure default arguments.
Along with an extension of the ConstructorDecl placeholder code, this allows
us to round-trip empty structs.
Swift SVN r5532
Per discussion on swift-dev, we'd prefer to have a "pointer-like" integer
with limited bit width, to reuse all the existing infrastructure for
pointer-like types, rather than invent another new data structure.
Swift SVN r5529
Also, explicitly list the top-level decls in a module. Eventually this
will be a proper lazily-loaded identifier-DeclID map, but for now it's
just a flat list of IDs to deserialize as soon as a lookup is
requested.
We can now parse and typecheck a file that imports typealiases of builtin
types.
Swift SVN r5325
This includes the reading half of BCRecordLayout metaprogramming, and
then a fairly straightforward deserialize-and-cache implementation in
ModuleFile. Once again, this is based on Clang's module implementation:
decls and types are referred to by an ID, which is used as an index into
an array, which contains offsets to the definitions of the decl/type in
the "decls-and-types" block in the serialized module.
In order to test the feature, the code is currently eagerly deserializing
all declarations. This will be partially fixed in the next commit.
Swift SVN r5324
...but don't do anything with them yet. This does check that they're being
correctly serialized, though.
This introduces a new ADT, PointerIntUnion, which like PointerUnion is an
efficient variant type using the lowest bit of data as a discriminator.
By default, the union can store any pointer-bits-minus-one-sized integer,
but both the integer type and the underlying storage type can be
customized.
Swift SVN r5321
Like Clang, ModuleFile contains state about reading the serialized module,
while SerializedModuleLoader takes the place of ASTReader in tracking
cross-module data. I'm diverging from Clang's architecture a bit here by
pushing the actual deserialization logic into ModuleFile.
No functionality change.
Swift SVN r5174
