Commit Graph

5 Commits

Author SHA1 Message Date
Jordan Rose
fa3dd42c54 Don't parse function bodies in imported TUs.
...unless the functions are declared [transparent], or if we're in an
immediate mode (in which case we won't get a separate chance to link
against the imported TUs).

This is an optimization that will matter more when we start dealing with
Xcode projects with many cross-file dependencies, especially if we have
some kind of implicit import of the other source files in the project.

In the future, we may want to parse more function bodies for the purpose
of inlining, not just the transparent ones, but we weren't taking
advantage of that now, so it's not a regression. (We're still not taking
advantage of it even for [transparent] functions.)

Swift SVN r7698
2013-08-28 22:53:28 +00:00
Jordan Rose
3e7eef56e7 Kill [stdlib] attribute.
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
2013-07-30 21:27:42 +00:00
Chris Lattner
c03d4454a0 implement support for a new [stdlib] attribute that can be slapped on an import decl.
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
2013-06-27 21:31:15 +00:00
Doug Gregor
8114ce16f8 Use the list of extensions of a nominal type for name lookup into that type.
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
2013-05-20 18:06:51 +00:00
Jordan Rose
ccae995f61 Use a list of module loaders instead of a single Clang importer.
This paves the way for having a Swift module importer. The eventual goal
here is to eliminate all explicit uses of the Clang module loader, but
I'm not going to push too hard on that for now.

Swift SVN r5092
2013-05-08 18:09:33 +00:00