getDisplayDecls() was introduced for ":print_module" and works slightly differently, e.g.
it will return the decls from a shadowed clang module, since we want to display them.
Swift SVN r7909
Add tools/lldb-moduleimport-test, which simulates LLDB importing modules
from the __apple_ast section in Mach-O files and use it to regression-test
the new API.
Swift SVN r7709
This is basically the same as doing a :print_decl on every decl in the module,
except that it does not print extensions that come from other modules, and
/does/ print extensions and operators that come from this module.
Does not yet work for Clang modules or the Builtin module.
Swift SVN r7601
In Swift, a module is expected to know which libraries it needs, rather than
having this specified by an external module map. While we haven't quite
designed this yet (frameworks get this for free in Clang, for example),
we can at least provide a simple option for the common case of a module
associated with a single library.
This will probably change in the future, so I left in the more general
deserialization code I was working on before simplifying the use case.
A loaded module can in theory specify any arbitrary frameworks or libraries
as dependencies, not just a single dylib.
Swift SVN r7583
...instead of just those that are re-exported. This will be used for
autolinking (and probably few other places).
As part of this, we get two name changes:
(1) Module::getReexportedModules -> getImportedModules
(2) TranslationUnit::getImportedModules -> getImports
The latter doesn't just get modules-plus-access-paths; it also includes
whether or not the import is re-exported. Mainly, though, it just didn't
seem like a good idea to overload this name when the two functions aren't
really related.
No tests yet, will come with autolinking.
Swift SVN r7487
This will be used to resolve properties and method calls on objects with
dynamic-lookup ("id") type. For now, this is tested in swift-ide-test
by using the -dynamic-lookup-completion option and providing a
-code-completion-token value.
Caveats/TODOs:
- As before, since we're using the global method pool, this isn't scoped by
module. We could do a per-module filter, but I don't know if that will
actually buy us much.
- Again, Clang's method pool does not include methods from protocols.
- Lookup by selector name cannot find properties with a customized getter
name. <rdar://problem/14776565>
- The Clang-side method pool is keyed by selector, but Swift wants to look
things up by method name, which maps to the first selector piece, so we
end up having to do a scan of all the selectors in the pool.
Swift SVN r7330
With this, we can now get a list of all class members* available in the
current translation unit, which will be necessary for doing id-style
dynamic lookup (inferring which method you're referring to when the base
type is some magic "dynamic lookup" type).
* Including members of protocols, since a class we don't know about could
have implemented the protocol.
Since there is no code currently using this, I've added a new mode to
swift-ide-test to just dump all class members -- what will eventually
happen when you code complete on a dynamic lookup type. This mode will
go away once the other pieces of id-style lookup are in place.
Swift SVN r7287
...by adding a new callback to ModuleLoader: loadDeclsConformingTo.
This is used only when the type checker doesn't have enough contextual
information to resolve an expression involving a literal, so it's
possible many *LiteralConvertible types will never be loaded.
Deserialization of types with conversion methods is still eager, since
there's no easy hook to tell when they're needed, but the list has been
renamed to refer to any decls that need to be eagerly deserialized, in
case we need it for other purposes in the future.
This probably won't help much in a real program, but it cuts the test
run time by about 5-10% in my build.
Swift SVN r7268
This switches from simple lists of decls to name-based on-disk hash tables,
which allows decls to be loaded lazily when doing simple lookup (but not
code completion, at least not yet).
The on-disk hash table implementation is borrowed from Clang; eventually
it will be pushed down to LLVM's Support library. (Fortunately the
implementation is header-only.)
This breaks a few tests that rely on magic protocols like
IntegerLiteralConvertible, because the type checker won't have seen the
types that conform to those protocols yet. This will be fixed by doing
an additional "hey, modules, got any of these?" lookup.
Swift SVN r7259
Now that we have true serialized modules, the standard library can import
the Builtin module without any special direction (beyond -parse-stdlib),
and anyone can include those modules without special direction.
Swift SVN r6752
This involved threading it through ModuleLoader, as with all the other
module-generic callbacks. I plan to collapse a bit of the chaining, but
unfortunately not that much.
This brings back the CodeCompletion tests.
Swift SVN r6527
Rather than automatically re-exporting or not re-exporting every import in
a TranslationUnit, we'll eventually want to control which imports are local
(most of them) and which imports are shared with eventual module loaders.
It's probably not worth implementing this for TranslationUnit, but
LoadedModule can certainly do something here.
Currently, a LoadedModule is even more permissive than a TranslationUnit:
all imports are re-exported. We can lock down on this once we have a
re-export syntax.
Swift SVN r6523
...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
