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
Give oneof bodies syntax consistent with other NominalTypes. Give oneof elements first-class declaration syntax using the 'case' introducer, as suggested by Jordan. Oneofs can contain 'case' decls, functions, properties, and constructors, but not physical ivars. Non-oneof scopes cannot contain 'case' decls. Add some QoI to the oneof 'case' parser to also parse and complain about things that resemble switch 'case' labels inside decl contexts.
Swift SVN r6211
I had previously thought these didn't appear in public decls, but they're
used when you extend a generic class without generic arguments.
Swift SVN r6187
Currently, we are eagerly deserializing extensions. This probably isn't
what we want to do in the long run, but until lookup settles down a bit
it's not worth optimizing.
Swift SVN r6186
Take advantage of the fact that a function can never be both a conversion
method and an assignment operator to pack both flags into the same bit in
the serialized record.
Swift SVN r6185
For consistency purposes, VarDecls in the subscript pattern now have the
enclosing nominal as their decl context, rather than no decl context at all.
Swift SVN r6177
Turns out we actually have to serialize the name of an archetype, because
it may be different from the declaration in a context where it has been
unified with another archetype. Found on attempting to emit a module for
the standard library.
(This is actually the commit that uses the two-container for_each
introduced in the last commit.)
Swift SVN r6172
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
The way llvm::BitstreamCursor works is that reading an end-of-block
code will pop the current block off the stack, along with all its
record abbreviation codes. This means we’d no longer know how to
read any records. Fix this by telling the cursor not to auto-pop blocks
any time we’re doing a tentative read.
Swift SVN r6135
Since accessor FuncDecl have a backreference to the VarDecl they are
attached to, we were getting re-entrant deserialization issues. Fix
this by just not serializing the backreference and relying on the
property being deserialized first.
Swift SVN r6134
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
...in a quest for completeness. ArrayTypes don't actually work yet
(single-dimensional arrays are typed as slices), but when they do the test
that is currently XFAIL'd should start passing.
With this, all non-transient types can now be serialized and deserialized.
Swift SVN r6101
This is the first time reaching the case where the module refers to a type
that also appears in the TU and tries to modify it. This shouldn't be a
problem for any of the other types we currently serialize besides
BoundGenericType and ArraySliceType because we either don't try to modify
them after creation or are guaranteed a new type object.
Swift SVN r6060
PolymorphicFunctionTypes are built on GenericParamLists, which are
owned by decls that introduce generic parameters. This made deserializing
them a pain, because they /cannot/ be recreated in isolation -- the decl
provides some context. Rather than try to come up with a very generic way
to serialize these, this patch just records the GenericParamList of every
decl, allowing the type to be serialized with a reference to the decl
instead of to the param list. Deserialization can then just pluck the list
back out of the decl.
According to Doug and Joe, PolymorphicFunctionType's due for a refresh
anyway, so this kind of hackery / kludgery is acceptable.
With this change, we can now handle generic structs and generic functions
inside generic structs.
Swift SVN r6032
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
Instead, special-case cross-references to use the empty identifier as the
name of the Builtin module. This way imported modules will be able to use
builtin types and functions without the main TU having access.
Swift SVN r5947
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
This is currently implemented in terms of an access path of identifiers,
with a type check at the very end to pick the correct overload for a
function. Of course there are plenty of things missing here:
- function overloading on parameter names (selector pieces)
- access to values inside extensions
- generics (as everywhere)
This allows the serialization tests to be built against the standard
library instead of requiring -parse-stdlib.
Swift SVN r5797
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
This revealed an issue where a function's pattern may have variables that
depend on the function itself; it's therefore important that the function
decl is recorded in the decl map before its argument patterns are loaded.
We should now support structs, concrete properties, and computed properties.
Swift SVN r5745
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
Like everything else, there are several caveats: no generic params, no
attributes, and (for now) no arguments. Pattern support is coming next.
Swift SVN r5701
The only tricky thing here is that the calling convention enum needs to be
stable in the module format, so it's marshalled in and out by helper
functions when crossing serialization boundaries.
Swift SVN r5699
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
