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
