...and use it for shadowed modules (e.g. the Clang module "Foundation"
referenced by the Swift module "Foundation"), so that we can actually
find "NSString" when building AppKit.
Additionally, record shadowed modules as dependencies, so that they can
be loaded when the adapter module is loaded.
Swift SVN r6522
This causes the SourceLoader to recursively parse the imported module in standard
library mode, giving it access to the Builtin module.
This is all a terrible hack and should be ripped out with great victory someday, but
until we have binary modules that persist the build setting used to produce the
module, this is the best we can do.
Swift SVN r5847
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
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
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
