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
The writer stores the paths to the .swift files, the reader just loads
those .swift files. Fun!
No version validation yet. No separate ModuleReader class yet. No use of
the SerializedModule architecture yet, except for creating a dummy module
when the .sm file is corrupted.
Swift SVN r5164
Based on feedback by Doug. This signature is fairly arbitrary: it's the
UTF-8 encoding of U+2828 SPARKLES, followed by the number 14 to represent
2014. (Hopefully the format will have stabilized by 2014.)
(Why not 0x00 or 0x01 for the last byte? Because it's more likely we'll
collide with someone else being cute. Why not 0x0D / 13? Because that's
\r and could conceivably appear in real Unicode text. No one uses 0x0E
these days.)
Swift SVN r5134
This adds names to the other blocks and records in the file.
The tests now require llvm-bcanalyzer to run; please build that along
with 'FileCheck' and 'not'.
Swift SVN r5109
Eventually this will include both modules and source files that the
emitted module depends on, but for now it's just going to be used for
testing purposes to forward to normal source loaders.
Swift SVN r5108
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
