subject of a conformance constraint (e.g., T : Foo) and both types of
a same-type constraint need to be generic parameters of nested types
thereof. The latter actually prohibits code like, e.g.,
func f<R : Range requires R.Element == Int>()
which is something we may very well want to bring back into the
language in the future.
Swift SVN r2411
potential archetypes, replacing it with a 'parent' pointer that allows
a potential archetype to figure out its full name and its depth by
walking the parent chain. No actual functionality change.
Swift SVN r2409
placed on generic parameters and associated types within the generic
parameter clause, expands those requirements out to form the complete
set of requirements, then assigns archetypes for each of the generic
parameters and their nested types (recursively).
Swift SVN r2379
analysis for patterns.
Major changes:
1. We no longer try to compute the types of functions in the parser.
2. The type of a function always matches the type of the argument patterns.
3. Every FuncDecl now has a corresponding FuncExpr; that FuncExpr might not
have a body, though.
4. We now use a new class "ExprHandle" so that both a pattern and a type
can hold a reference to the same expression.
Hopefully this will be a more reasonable foundation for further changes to
how we compute the types of FuncDecls in generics and for the implementation
of type location information.
Swift SVN r2370
and Int[].
Type resolution for types named in ExtensionDecls remains a part of name-binding; it has to use more restrictive rules because we can't perform general member lookup until
we've resolved all the types named in ExtensionDecls.
Swift SVN r2313
Add a couple other misc pieces necessary for semantic analysis of members of
generic types. We're now up to the point where we can actually construct a
useful AST for small testcases.
Swift SVN r2308
they need to be substituted away for any type containing them to be
useful. A nice side-effect of this is that we'll actually properly
walk into the source type when a generic function returns, e.g., a
tuple type that involves type parameters not resolved by the input
arguments.
Swift SVN r2302
the various NominalDecl subclasses into a single NominalType* member
in NominalDecl. Use it to make TypeDecl::getDeclaredType() more
efficient/simpler, and simplify the ProtocolDecl/ProtocolType
interaction along the way.
No functionality change.
Swift SVN r2298
resolution. When we see a polymorphic function type, we substitute
"deducible generic parameter" types for each of the generic
parameters. Coercion then deduces those deducible generic parameter
types. This approach eliminates the confusion between the types used
in the definition (which must not be coerced) and the types used when
the generic function is referenced (which need to be coerced).
Note that there are still some terrible inefficiencies in our handling
of these types.
Swift SVN r2297
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
coercion. Overload resolution uses this argument deduction when
dealing with generic functions, to determine when we can invoke a
generic function. When a generic function is selected, we create a
SpecializeExpr wrapping the DeclRefExpr to the generic function.
This is sufficient to type-check calls to simple things like a call to
func identity<T>(x : T) -> T { return x }
with a value of known type. However, it's missing far too many pieces
to enumerate.
Swift SVN r2230
