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
UnqualifiedLookup to ask an external source for
names. There are two phases to this external lookup:
- Before consulting globals in other modules,
UnqualifiedLookup calls lookupOverrides() to see
if there are any results that should override the
results from modules. (N.b.: these should not be
able to override names that are locally defined.)
- After consulting globals in other modules,
UnqualifiedLookup as a last resort calls
lookupFallbacks() to see if there's anything out
there at all that could serve that name. This may
be more computationally expensive.
These hooks are used by LLDB's expression parser to
resolve names for persistent variables (akin to the
existing $0, $1, ... variables) and variables local
to the current frame.
Swift SVN r9014
Instead of relying on the subpattern being a well-formed TuplePattern, let's track our own subelements so we can associate them to properties and validate them ourselves.
Swift SVN r8771
Instead, pass a LazyResolver down through name lookup, and type-check
things on demand. Most of the churn here is simply passing that extra
LazyResolver parameter through.
This doesn't actually work yet; the later commits will fix this.
Swift SVN r8643
and remove DeclContext base class from FuncDecl, ConstructorDecl and
DestructorDecl
This decreases the number of DeclContexts to 7 and allows us to apply
alignas(8) to DeclContext.
Swift SVN r8186
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
If we allowed dynamic lookup to find a member of a generic class, we
would then have to figure out the generic arguments. Technically, it's
possible that we could deduce the generic arguments from the signature
of the function we found... but it feels unlikely that we'd get the
right answer often enough to make it useful. So don't do that.
Swift SVN r7758
Unlike normal overload resolution, where we always want the
most-specialized, overriding result, overload resolution for dynamic
lookups favors results in superclasses to those in subclasses, because
we want to put the least requirements on the object
type. Additionally, we don't allow overload resolution to select among
results that come from different classes or protocols.
Swift SVN r7743
When performing member lookup into an existential that involves the
DynamicLookup protocol, look into all classes and protocols for that
member. References to anything found via this lookup mechanism are
returned as instances of Optional.
This introduces the basic lookup mechanics into the type
checker. There are still numerous issues to work through:
- Subscripting isn't supported yet
- There's no SILGen or IRGen support
- The ASTs probably aren't good enough for the above anyway
- References to generics will be broken
- Ambiguity resolution or non-resolution
Thanks to Jordan for the patch wiring up DynamicLookup.
Swift SVN r7689
Apparently, this code was written this way because getCanonicalType() on a
TypeAliasDecl which represented generic parameter used to assert().
Swift SVN r7447
Previously, we were creating the type corresponding to
class/struct/union declarations as part of creating the declaration
node, which happens at parse time. The main problem with this (at the
moment) occurs with nested nominal types, where we'd end up with the
wrong "parent" type when the type was nested inside an extension
(because the extension hadn't been resolved at the time we accessed
the parent's type). Amusingly, only code completion observed this,
because the canonical type system hid the problem. The churn in the
code-completion tests come from the fact that we now have the proper
declared type for class/struct/union declarations within extensions.
Take a step toward order-independent type checking by setting the type
of a class/struct/union declaration in type checking when we either
find the declaration (e.g., due to name lookup) or walk to the
declaration (in our walk of the whole translation unit to type-check
it), extending the existing TypeChecker::validateTypeDecl() entry
point and adding a few more callers.
The removeShadowedDecls() hack is awful; this needs to move out to the
callers, which should be abstracted better in the type checker anyway.
Incremental, non-obvious step toward fixing the representation of
polymorphic function types. This yak has a *lot* of hair.
Swift SVN r7444
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
...so, add a templated overload that ensures that lambdas aren't copied,
so that callers don't need to add an explicit makeStackLambda().
No functionality change.
Swift SVN r7303
This makes lookupVisibleDecls use the same code path as qualified and
unqualified lookup. This is more expensive, because it needs to actually
collect a list of /all/ decls in order to properly compute shadowing
information, but this list is not likely to change once the set of imports
has been computed, so we can cache it.
Swift SVN r7168
Deduced associated types are implemented by allowing name lookup into
a type to find the requirements in the protocols to which that type
conforms. If the protocol conformance produced the witness for the
requirement via deduction (or, eventually, default definitions), we
use the deduced witness; otherwise, the actual declaration within the
type itself is used.
Previously, the AST-level lookup was deciding whether to filter out
protocol requirements based on the conformance information in the
AST. However, this lead to ordering dependencies, because the type
checker doesn't record the conformances in the AST until we've visited
all of the conformances for a given declaration. This lead to an
oddity where one could have one conformance depend on another's
deduced associated type, but only if that conformance was on a later
extension. Fixes <rdar://problem/14685674>.
As part of this, teach the type checker to re-use normal conformances
that get deserialized, rather than creating new ones. Otherwise, we'll
end up with two different copies of the same conformance running
around.
Swift SVN r7075
This includes proper rules for function overloads (i.e. shadowing by type)
and allowing type lookup to find a type even if it has the same name as
a non-type.
lookupVisibleDecls does not use this behavior yet.
Swift SVN r7016
This required a general reworking of the algorithm for qualified name lookup.
Originally, qualified lookup only applied to a module -- not to its exports.
This meant that "Cocoa.NSWindow" would fail, so that was changed to grovel
through all exported modules looking for decls if the top-level module didn't
provide any.
Now, we actually do a breadth-based search, stopping at each level if decls
are provided for a given name. We also now prefer scoped imports to unscoped
imports, so "import abcde" and "import struct asdf.D" will result in a
(qualified) reference to 'D' being unambiguous.
Not working yet:
- Shadowing for unqualified lookup.
- Shadowing by types, so that overloads from this module can merge with
overloads from its exports.
Swift SVN r7014
This is the Swift equivalent of allowing Cocoa.NSWindow to find
AppKit.NSWindow (or AppKit.NSWindow.NSWindow, really). Some of these
error messages could be improved, but the basic semantics are correct.
Swift SVN r6855
Note that the import kind is not checked yet; this is effectively our old
behavior for "import swift.print".
Infrastructure: move Module::forAllVisibleModules out-of-line, and add
makeStackLambda to STLExtras for using a non-escaping lambda with
std::function.
Swift SVN r6852
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
Detect duplicate and multiple inheritance, clean up diagnostics, and
unify the code that checks the types in the inheritance clause with
the code that sets the superclass and protocol lists.
Swift SVN r6706
This iterates over a module's exports, transitively, in an unspecified
but deterministic order. This is useful for any sort of lookup and for
managing transitive inclusion. It also allows us to remove the hack in
Sema for loading a Clang module's adapter module, and just rely on the
previous commit.
Swift SVN r6699
This makes it very clear who is depending on special behavior at the
module level. Doing isa<ClangModule> now requires a header import; anything
more requires actually linking against the ClangImporter library.
If the current source file really can't import ClangModule.h, it can
still fall back to checking against the DeclContext's getContextKind()
(and indeed AST currently does in a few places).
Swift SVN r6695
Standardize on the more-common "superclass" and "subclass" terminology
throughout the compiler, rather than the odd mix of base/derived and
super/sub.
Also, have ClassDecl only store the Type of the superclass. Location
information will be part of the inheritance clause for parsed classes.
Swift SVN r6687
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 change also exposes and fixes a bug where we would improperly filter
shadowed declarations. removeShadowedDecls() assumed that all decls had the
same name, but when it is used from lookupVisibleDecls(), this is not true.
Thus, we group decls not only by signature, but also by name.
Swift SVN r6460
This is a temporary hack until we properly make these carry
their own generic parameters.
This removes the last valid way to get UnboundGenericTypes in
a checked program.
Swift SVN r6373
