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
