which other archetypes (such as associated types) are based. Give
primary archetypes an index, to help with recording substitutions in
the near future.
Swift SVN r2239
archetype conforms from a list of Types (each of which is existential)
to the minimized, sorted list of protocol declarations as used by
canonical protocol composition types. This stable list is more
suitable for IR generation.
Swift SVN r2238
semantics into the AST library where they don't belong. These were
made obsolete by the recent TypeCheckExpr::build(Member)?RefExpr()
refactoring.
Swift SVN r2222
results of member lookup, and eliminate all uses of
MemberLookup::createResultAST(). The AST library should not be
performing this semantic analysis.
Swift SVN r2221
reference expressions, introducing two routines on TypeChecker
(buildRefExpr and buildMemberRefExpr) that are intended to be the sole
generators of ASTs.
Updated all but one caller for member reference expressions, the
terrible MemberLookup::createResultAST(), which still calls into the
AST library to build nodes.
Swift SVN r2219
base of the expression is ignored, as it will be for references to
static member functions or when the base is actually of metatype
type. Then, always also one to access the type of the base, even if
it's a metatype type.
Use this information to simplify our handling of archetype member
reference expressions, which can refer to either members of the
meta-archetype or of an instance of the archetype. This allows us to
refer to an instance methodr of an archetype type (e.g., T.method) and
get back its curried form ([byref] T) -> inputs -> result.
Swift SVN r2218
used in the very narrow case where we were converting from one
protocol type to another (super) protocol type. However, ErasureExpr
now handles this case via its null conformance entries (for the
"trivial" cases), and can cope with general existential types where
some conversions are trivial and others are not.
The IR generation side of this is basically just a hack to inline the
existing super-conversion code into the erasure code. This whole
routine will eventually need to be reworked anyway to deal with
destination types that are protocol-conformance types and with source
types that are archetypes (for generic/existential interactions).
Swift SVN r2213
functions. This involves a few steps:
- When assigning archetypes to type parameters, also walk all of the
protocols to which the type parameter conforms and assign archetypes
to each of the associated types.
- When performing name lookup into an archetype, look into all of
the protocols to which it conforms. If we find something, it can be
referenced via the new ArchetypeMemberRefExpr.
- When type-checking ArchetypeMemberRefExpr, substitute the values
of the various associated types into the type of the member, so the
resulting expression involves the archetypes for the enclosing
generic method.
The rest of the type checking essentially follows from the fact that
archetypes are unique types which (therefore) have no behavior beyond
what is provided via the protocols they conform to. However, there is
still much work to do to ensure that we get the archetypes set up
correctly.
Swift SVN r2201
protocols it conforms to. Use this list when substituting into a
protocol's signature, so that we get an existential type back. For
example:
var e : Enumerable
var r = e.getElements()
r.getFirstAndAdvance() // okay: r is a range.
Swift SVN r2139
protocols the underlying type of the type alias shall conform to. This
isn't super-motivating by itself (one could extend the underying type
instead), but serves as documentation, makes typealiases provide the
same syntax as other nominal types in this regard, and will also be
used to specify requirements on associated types.
Swift SVN r2133
We probably need to add some sort of data structure to represent this information, but as a proof of concept the current code appears to work. I'm still working out how to make sure the parser doesn't prematurely bind names and how to make name-binding use it where appropriate (and avoid it when we don't need it, because no matter how efficient we make it, it will still be relatively expensive).
Swift SVN r2112
