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
This replaces the obscure, inefficient lookup into extensions with
something more straightforward: walk all of the known extensions
(available as a simple list), then eliminate any declarations that
have been shadowed by other declarations. The shadowing rules still
need to consider the module re-export DAG, but we'll leave that for
later.
As part of this, keep track of the last time we loaded extensions for
a given nominal type. If the list of extensions is out-of-date with
respect to the global generation count (which tracks resolved module
imports), ask the modules to load any additional extensions. Only the
Clang module importer can currently load extensions in this manner.
Swift SVN r5223
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
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
