We can bikeshed on this later, but for now we can use a very explicit
extension that has no chance of stepping on any existing extension.
Swift SVN r5239
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 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
Like Clang, ModuleFile contains state about reading the serialized module,
while SerializedModuleLoader takes the place of ASTReader in tracking
cross-module data. I'm diverging from Clang's architecture a bit here by
pushing the actual deserialization logic into ModuleFile.
No functionality change.
Swift SVN r5174
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
