This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
Now that everything is done in terms of FileUnits, we don't need LoadedModule
anymore, and now that FileUnits just use virtual dispatch, we don't need to
indirect through ModuleLoader to distinguish them.
This doesn't quite simplify as much as it could, because the next change is
going to combine TranslationUnit and Module.
Swift SVN r10836
Part of the FileUnit restructuring. A Clang module (whether from a framework
or a simple collection of headers) is now imported as a TranslationUnit
containing a single ClangModuleUnit.
One wrinkle in all this is that Swift very much wants to do searches on a
per-module basis, but Clang can only do lookups across the entire
TranslationUnit. Unless and until we get a better way to deal with this,
we're stuck with an inefficiency here. Previously, we used to hack around
this by ignoring the "per-module" bit and only performing one lookup into
all Clang modules, but that's not actually correct with respect to visibility.
Now, we're just taking the filtering hit for looking up a particular name,
and caching the results when we look up everything (for code completion).
This isn't ideal, but it doesn't seem to be costing too much in performance,
at least not right now, and it means we can get visibility correct.
In the future, it might make sense to include a ClangModuleUnit alongside a
SerializedASTFile for adapter modules, rather than having two separate
modules with the same name. I haven't really thought through this yet, though.
Swift SVN r10834
Part of the FileUnit restructuring. A serialized module is now represented as
a TranslationUnit containing a single SerializedASTFile.
As part of this change, the FileUnit interface has been made virtual, rather
than switching on the Kind in every accessor. We think the operations
performed on files are sufficiently high-level that this shouldn't affect us.
A nice side effect of all this is that we now properly model the visibility
of modules imported into source files. Previously, we would always consider
the top-level imports of all files within a target, whether re-exported or
not.
We may still end up wanting to distinguish properties of a complete Swift
module file from a partial AST file, but we can do that within
SerializedModuleLoader.
Swift SVN r10832
Qualified lookup depends not only on the current module but actually the
current file, since imports are file-scoped by default. Currently this only
affects lookup into other modules (e.g. "Foundation.NSString"), but this
could also be used for extension filtering.
This breaks one name resolution test, but the refactoring in the next
commit changes everything anyway and will restore the test.
Swift SVN r10831
The goal of this series of commits is to allow the main module to consist
of both source files and AST files, where the AST files represent files
that were already built and don't need to be rebuilt, or of Swift source
files and imported Clang headers that share a module (because they are in
the same target).
Currently modules are divided into different kinds, and that defines how
decls are looked up, how imports are managed, etc. In order to achieve the
goal above, that polymorphism should be pushed down to the individual units
within a module, so that instead of TranslationUnit, BuiltinModule,
SerializedModule, and ClangModule, we have SourceFile, BuiltinUnit,
SerializedFile, and ClangUnit. (Better names welcome.) At that point we can
hopefully collapse TranslationUnit into Module and make Module non-polymorphic.
This commit makes SourceFile the subclass of an abstract FileUnit, and
makes TranslationUnit hold an array of FileUnits instead of SourceFiles.
To demonstrate that this is actually working, the Builtin module has also
been converted to FileUnit: it is now a TranslationUnit containing a single
BuiltinUnit.
Swift SVN r10830
Previously we would cache the results of operator lookup whether or not the
operator we found came from an imported module. Since different source files
can have different imports, it's not correct to automatically share operators
from imported modules with all files in the translation unit.
This still isn't fully correct; the current logic prefers operators from
local imports over operators implicitly available from other source files.
Swift SVN r9683
Anywhere that assumes a single input file per TU now has to do so explicitly.
Parsing still puts all files in a single SourceFile instance; that's next on
the list.
There are a lot of issues still to go, but the design is now in place.
Swift SVN r9669
The operator lookup cache already lived in SourceFile, but we need to be
able to look up operators on a per-SourceFile basis. Different files can
have different imports. The interface previously distinguished between
"no operator found" and "error", but none of the call sites were making
use of this distinction, and indeed some were misusing the return value
(Optional<SomeOperatorDecl *>). Now the lookup functions just return
operator decl pointers, which may be null.
Swift SVN r9668
Each one has a different kind of lookup cache anyway, and there's no real
reason to have them share storage at the cost of type-safety.
Swift SVN r9242
Being able to pass -l to the driver isn't so interesting, and it's an
extra field that lives on TranslationUnit for no reason. Just remove it.
This doesn't interfere with autolinking, i.e. inferring -l flags based on
imported modules.
Swift SVN r9241
Right now this is just an extra layer of indirection for the decls,
operators, and imports in a TU, but it's the first step towards compiling
multiple source files at once without pretending they're all in a single
file. This is important for the "implicit visibility" feature, where
declarations from other source files in the same module are accessible
from the file currently being compiled.
Swift SVN r9072
Semantic context describes the origin of the declaration and serves the same
purpose as opaque numeric "priority" in Clang -- to determine the most likely
completion.
This is the initial implementation. There are a few opportunities to bump the
priority of a certain decl by giving it SemanticContextKind::ExprSpecific
context that are not implemented yet.
Swift SVN r9052
Now that TypeChecker is being used to check all sorts of things (not all
from a single TU), it's not really correct to have a single top-level TU
that gets used everywhere. Instead, we should be using the TU that's
appropriate for whatever's being checked. This is a small correctness win
for order-independent type-checking, but is critical for multi-file
translation units, which is needed for implicit visibility.
This basically involves passing around DeclContexts much more.
Caveat: we aren't smart about, say, filtering extensions based on the
current context, so we're still not 100% correct here.
Swift SVN r9006
Teach a BoundGenericType to compute its own substitutions, which
allows AST clients to create new bound generic types without the aid
of the type checker.
This eliminates the TypeChecker::validateTypeSimple() abomination as
well as the need for the BoundGenericType AST validation step. There
is still more cleanup to do in this area.
Note that BoundGenericType::getSubstitutions() now accepts a module
parameter, which is the place from which we will look for
conformances. This is a baby step toward properly modeling the
conformances as part of the bound generic type, and is nowhere near
complete.
Swift SVN r8193
This eliminates the need for the hackish
LazyResolver::resolveUnvalidatedType() entry point, making type
substitution on ASTs far more useful. As part of this, teach it to
handle conformances for existentials and archetypes.
Swift SVN r8169
This allows AST clients to perform type substitutions without
requiring a type checker. Test this by performing substitutions within
the AST verifier.
Swift SVN r8166
Introduce an AST operation that, given a type and a protocol, determines
whether the type conforms to the protocol and produces the protocol
conformance structure. Previously, this operation was only available
on the type checker, requiring many callbacks from the AST to the type
checker during AST substitution operations (for example).
Now, we only call back into the type checker when we hit a case where
we see an explicit conformance in the AST, but the actual
ProtocolConformance object has not yet been built due to lazy type
checking.
Note that we still require a resolver (i.e., a TypeChecker) in a few
places, although we shouldn't need it outside of lazy type
checking. I'll loosen up the restrictions next.
There's a minor diagnostics regression here that will be cleaned up in
a future commit.
Swift SVN r8129
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
Clean up the "can be accessed by dynamic lookup" predicate so that it
checks for a generic context. We no longer need to do the checking in
name lookup, since this means that the dynamic lookup table won't have
anything we can't use (thanks Jordan!). Drop the [objc] allowance for
members of a generic context: it still leaves us with a very weird
case of messaging something when we can't even figure out the type
that we think the object has.
Extend the walk searching for members to include inner classes within
structs, so we get all of the members globally.
Swift SVN r7799
Previously, export control (via [exported]) only applied to modules that
had been serialized -- anything imported in a TranslationUnit was
automatically considered exported. This was done to make life easier when
dealing with the main source file, but it turns out we're going to want to
load other source files as imports, and export control should work there too.
Now, the module iteration methods (Module::forAllVisibleModules,
namelookup::lookupInModule, etc.) can consider the module being passed as
"top-level", meaning its private imports are visible as well. Otherwise,
proper export control is observed even for imported TranslationUnits.
This required a number of test changes involving Swift adapter modules that
forgot to re-export their Clang modules.
Swift SVN r7783
Per discussion with Doug, there's no reason why this should not work:
class Outer {
class Inner {
func extract() { ... }
}
}
var obj : DynamicLookup = ...
obj.extract!()
Swift SVN r7763
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
