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
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
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
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
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
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
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
Alternately, "add a system of ridiculous overkill for bitcode record layout",
in the spirit of DRY over YAGNI. It /is/ much more concise than the LLVM way.
Use this to emit a sketch of Clang's PCH control block, although nothing's in
there yet besides "version 1.0" and the LLVM revision number; the latter is
more "proof of concept" than actually useful. We should figure out a good
way to identify trunk Swift compilers; this shouldn't be difficult.
Swift SVN r5107
