...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
The idea for now is that this is a SIL-only type used for
representing the storage of a weak or unowned reference.
Having it be its own type is pretty vital for reasonable
behavior in SIL and IR-generation, and it's likely that
this will surface into runtime metadata as well (hence
the mangling).
I've implemented a bunch of things that technically I don't
think are necessary if this stays out of the typechecker,
but it's easier to implement half-a-dozen "recurse into
the child type" methods now that it would be to find them
all later if we change our minds.
Swift SVN r6091
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
We decided to go with 'var' as a distributive pattern introducer which applies to bare identifiers within the subpattern. For example, 'var (a, b)' and '(var a, var b)' would be equivalent patterns. To model this, give 'var' its own AST node with a subpattern and remove the introducer loc from NamedPattern.
Swift SVN r5824
This adds builtin types Builtin.VecNxT, where N is a natural number
and T is a builtin type, which map down to the LLVM type <N x T>.
Update varous builtins to support vector arguments, e.g., binary
operations, comparisons, negation. Add InsertElement and
ExtractElement builtins for vectors.
On top of these builtins, add Vec4f and Vec4b structs to the standard
library, which provide 4xFloat and 4xBool vectors, respectively, with
basic support for arithmetic. These are mostly straw men, to be burned
down at our leisure.
Some issues as yet unresolved:
- Comparisons of Vec4f'ss are producing bogus Vec4b's, which I
haven't tracked down yet.
- We still don't support the shuffle builtin, although it should be
easy
- More testing!
Swift SVN r5820
I talked to John about parsing patterns today, and because of the magnitude of name-lookup-dependent ambiguities between patterns and expressions, we agreed that at least for a first-pass implementation it makes sense to parse patterns as extensions of the expr grammar and charge name binding with distinguishing patterns from expressions. This gets us out of needing the concept of an "unresolved pattern", at least in the short term.
Swift SVN r5808
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
Introduce Pattern subclasses for the 'is T', 'T(<pattern>)', and '<expr>' pattern syntaxes we'll be introducing for pattern-matching "switch" statements. Also add an 'UnresolvedCalLPattern' to act as an intermediate for name lookup to resolve to a nominal type, oneof element, or function call expression pattern. Since we'll need to be able to rewrite patterns like we do expressions, add setters to AST nodes that contain references to subpatterns. Implement some basic walking logic in places we search patterns for var decls, but punt on any more complex type-checking or SILGen derived from these nodes until we actually use them.
Swift SVN r5780
Though it adds a small bit of bloat to the serialized modules, it's
necessary for llvm-bcanalyzer-based tests, and it's really not something
to worry about anyway.
Swift SVN r5750
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
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
This serializes structs, but not any of their members. Unfortunately, all
structs have members (the implicit constructor at the very least), so this
doesn't actually do anything at all and is completely untested.
Immediate goal: round-tripping an empty struct.
Swift SVN r5530
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
Clang modules have a clever way to share decl and type IDs, by saying
"this range of IDs comes from this other module". Swift modules have to
be resilient, however, and so this is not a viable solution.
We still use 0 as a special ID for null decls and types, when applicable.
Swift SVN r5323
I avoided this the first time around because I wasn't sure if Type really had
low bits free, but it looks like we're relying on that elsewhere. If we ever
use up all the bits in Type we'll have to rip all these up, but for now it's
better to stick with what's in LLVM.
Swift SVN r5322
Just a starting point -- builtin types are serialized by name, and the
IdentifierType necessary to /refer/ to a typealias is completely skipped.
This should be enough to start working on deserialization, however.
Swift SVN r5320
The bringup hack, again, is to just process the module source files as a
TranslationUnit if the module doesn't accurately represent the original
source. Currently this happens if the module is not empty, or if it imports
/anything/, since we don't actually serialize anything yet.
This also cleans up the decl/type serialization skeleton a bit.
Swift SVN r5238
This is basically modeled off of Clang's ASTWriter: write out all decls
and types en masse, then write out a list of offsets for quick access later,
and use the indexes into the offset lists as module-unique IDs for the decls
and types.
No decls or types are actually being serialized yet, and I haven't done
any of the work necessary for multi-module support (which would assume
offsets don't start at 0). There's also no reader support yet.
Swift SVN r5237
