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
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
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
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
Per r6154, this is now dead code. The only places we allow default
arguments will be visited by normal type validation, so there's
nothing specific to do here.
Swift SVN r6157
When checking a type's conformance against a protocol, we can deduce
the values of associated types. Make these associated types visible to
qualified name lookup so that (for example) VectorEnumeratorType does
not need to define the Element type. It is deduced from the signautre
of next(), and made available as, e.g.,
VectorEnumeratorType<Int>.Element through the Enumerator protocol
conformance. Fixes <rdar://problem/11510701>, but with some lingering
dependencies on lazy type resolution (<rdar://problem/12202655>).
Note that the infrastructure here is meant to be generalized to
support default implementations in protocols, but there are several
pieces still not in place.
Swift SVN r6073
guard access to the Builtin module (on one path), reducing the number
of ways non-stdlib and non-sil files have access to the builtin module.
Swift SVN r5767
library. We use the same (somewhat broken heuristics), they are
just implemented in another way.
The major functionality change is that previously, .sil files would
auto import "swift" if they started with a non-sil decl. Now they
never do.
Swift SVN r5731
by the SIL parser. Add a test that covers both local types, and types
that require looking through an import decl (Int, from the stdlib).
Swift SVN r5249
by TranslationUnit. This list existed solely to allow name lookup of
an unbound IdentifierType to know its DeclContext. Instead of indirecting
through this list, just store the DeclContext in the IdentifierType in its
uninitialized state.
This eliminates a really terrible performance fixme about scanning the list,
eliminates the management fiddling around with this list in the parser, and
is generally much cleaner.
Swift SVN r5246
The point of the assertion is to provide a type-dependent value that
evaluates to 'false', so that the static_assert will fire on any
instantiation of the template but not on the template itself.
Swift SVN r5176
This keeps AST insulated from the various module-loading interfaces, which
minimizes special-casing of the differences between ClangModule and the
(upcoming) SerializedModule.
Swift SVN r5096
Keep track of external definitions as they are created by broadcasting
them through a mutation listener interface. At name binding time, we
just cache them. When a type checker is alive, it immediately performs
any additional operations necessary on those types (e.g., declaring
implicit constructors).
This also eliminates some O(N^2) behavior in the type checker as well,
because we don't have to walk through all of the module imports to
find the external definitions. We just keep a single list in the
ASTContext along with our place in the list.
Fixes <rdar://problem/13769497>.
Swift SVN r5032
During name binding, associate func decls with operator decls. When parsing SequenceExprs, look up operator decls to determine associativity and precedence of infix operators. Remove the infix_left and infix_left attributes, and make the infix attribute a simple declared attribute [infix] with no precedence.
Operator decls are resolved as follows:
- If an operator is declared in the same module as the use, resolve to the declaration in the current module.
- Otherwise, import operator declarations from all imported modules. If more than one declaration is imported for the operator and they conflict, raise an ambiguity error. If they are equivalent, pick one arbitrarily.
This allows operator declarations within the current module to override imported declarations if desired or to disambiguate conflicting operator declarations.
I've updated the standard library and the tests. stdlib2 and some of the examples still need to be updated.
Swift SVN r4629
We use three tag bits on Expr*, Stmt*, Decl*, TypeBase* and SILTypeInfo*, and four on DeclContext*, so set the alignment of the pointed-to types formally with alignas(N) instead of relying on operator new passing down the right alignment to the allocator. Get rid of the informal T::Alignment members of these classes and pass alignof(T) to their allocators. Fix the 'operator new' of DeclContext subclasses so that we can actually use the four tag bits PointerLikeTypeTraits<DeclContext*> claims are available.
Swift SVN r4587
Implement a 'lookupVisibleDecls' API similar to Clang's that replicates the UnqualifiedLookup logic for walking through a given scope looking for decls. Use it to populate the completion list in the repl.
Still to be done: Clang module lookup via Clang's lookupVisibleDecls, and context deduction from dotted path expressions.
Swift SVN r4056
Types synthesized by the ClangImporter need to be visited at a minimum by TypeChecker::validateTypeSimple in order to set up generic substitutions and protocol conformances, so arrange for the ClangImporter to pile all of its emitted types into a list that can then be walked by the TypeChecker.
Swift SVN r3901
Note that the constructors we emit don't function yet, since they rely
on the not-yet-implemented class message sends to Objective-C
methods.
Swift SVN r3370
