The standard library likes to have default definitions for associated types,
which is good. Often the /choice/ of default type, however, is a type that
(indirectly) conforms to the very protocol containing the associated type.
Rather than try to make sure everything is present all at once, just delay
the deserialization of the default definition until it's actually requested.
This does swell the size of AssociatedTypeDecl by two words. I've filed
<rdar://problem/16266669> to remind myself to try to reduce this.
Part of <rdar://problem/16257259>
Swift SVN r14809
Teach name lookup to find complete object initializers in its
superclass when the current class overrides all of the subobject
initializers of its direct superclass.
Clean up the implicit declaration of constructors, so we don't rely on
callers in the type checker doing the right thing.
When we refer to a constructor within the type checker, always use the
type through which the constructor was found as the result of
construction, so that we can type-check uses of inherited complete
object initializers. Fixed a problem with the creation of
OpenExistentialExprs when the base object is a metatype.
The changes to the code completion tests are an improvement: we're
generating ExprSpecific completion results when referring to the
superclass initializer with the same signature as the initializer
we're in after "super.".
Swift SVN r14551
NominalTypeDecls and ExtensionDecls have a list of members. Rather than
eagerly populating that list when the nominal or extension is just referenced,
just include a pointer back to the ModuleFile, so that they can be
deserialized when we actually look into the decl. The design here is
general enough that we could do something similar with imported Clang decls.
Clang is even more lazy here: the on-disk representation is a hash table,
so lookup only forces deserialization of members with the same name. We
probably want that some day, but this might be enough to get by for now.
This is groundwork for loading partial ASTs, where eagerly deserializing
members leads to circular references we're not able to handle.
Swift SVN r11219
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
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
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
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
The type substitution still depends fairly heavily on the type
checker, which is accessed via the LazyResolver abstract
interface. That interface should get simpler, and become unnecessary
except to deal with lazy type checking, over time. At that point, it
will become optional, and Type::subst() will be usable without a type
checker around.
Swift SVN r8099
