been type-checked. The initialize constructed types are not (and
cannot be) canonical because archetypes aren't assigned until the
generic parameters in the current and outer contexts are
type-checked.
Test forthcoming as part of IRgen support for nested generics.
Swift SVN r2569
checker. There are a few related sets of changes here:
- Generic parameter lists have a link to their "outer" generic
parameter lists, so its easy to establish the full generic context
of an entity.
- Bound and unbound generic types now carry a parent type, so that
we distinguish between, e.g., X<Int>.Inner<Int> and
X<Double>.Inner<Int>. Deduction, substitution, canonicalization,
etc. cope with the parent type.
- Opening of polymorphic types now handles multiple levels of
generic parameters when needed (e.g., when we're substituting into
the base).
Note that the generics module implied by this representation restricts
what one can do with requirements clauses in nested generics. For
example, one cannot add requirements to outer generic parameters or
their associated types, e.g., this is ill-formed:
struct X<T : Range> {
func f<U requires T.Element : Range>() {}
}
The restriction has some precedent (e.g., in C#), but could be
loosened by rearchitecting how we handle archetypes in nested
generics. The current approach is more straightforward.
Swift SVN r2568
Fixing this causes a regression in generic argument deduction, presumably because something
deep in the generics overload set pruning logic isn't handling function types with unresolved
components. For now, I'm disabling the tests that check for this, but I'd obviously appreciate
it if someone could take a look.
Swift SVN r2527
types in a few ways:
- Actually check the extra requirements placed on associated types,
e.g., "T.Element : Ordered"
- Actually encode/store the protocol conformance information for a
BoundGenericType in the same way that we do for SpecializeExpr,
GenericMemberRefExpr, and GenericSubscriptExpr. Yay, consistency.
- Move the storage for the protocol conformance information into a
DenseMap in the ASTContext indexed by canonical BoundGenericType, so
it doesn't require inline storage in BoundGenericType.
Swift SVN r2517
member of a oneof/struct/class/extension to support types nested
within generic classes, e.g., Vector<Int>.ElementRange.
Most importantly, nominal types are no longer inherently canonical. A
nominal type refers to both a particular nominal type declaration as
well as its parent, which may be non-canonical and will vary. For
example, the variance in the parent makes Vector<Int>.ElementRange and
Vector<Float>.ElementRange different types.
Introduce deduction and substitution for nominal types. Deduction is
particular interesting because we actually do allow deduction of T
when comparing X<T>.Inner and X<Int>.Inner, because (unlike C++) there
is no specialization to thwart us.
Swift SVN r2507
polymorphic type when that type is nested within a generic type. The
type-checker still isn't ready to use these declarations in a sane way.
Swift SVN r2501
This is much more convenient for IRGen, and gives us a reasonable representation for a static
polymorphic function on a polymorphic type.
I had to hack up irgen::emitArrayInjectionCall a bit to make the rest of this patch work; John, please
revert those bits once emitCallee is fixed.
Swift SVN r2488
have a record of how the member is being specialized for the given
context. To do this, I also had to patch up the DeclContext for
template parameters.
Swift SVN r2483
type. This has remarkably little effect on type checking, because the
destructors themselves are never referenced by the AST after initially
type-checking them.
Swift SVN r2474
including the weird implicit one-of element declarations that end up in struct
types. Teach overload resolution and the type-checking of
ConstructorRefExprs how to specialize these polymorphic function types.
Swift SVN r2473
polymorphic function type. For example, given
struct X<T> {
func f(a : T) -> Int { }
}
The type of X.f is
<T> (this : [byref] X<T>) -> (a : T) -> Int
If we have a call to f, e.g.,
var xi : X<Int>
xi.f(5)
it will be represented as X.f specialized to type
(this : [byref] X<Int>) -> (a : Int) -> Int
and then called with 'xi' (DotSyntaxCallExpr) and finally 5
(ApplyExpr). The actual deduction of arguments is not as clean as I'd
like, generic functions of generic classes are unsupported, static
functions are broken, and constructors/destructors are broken. Fixes
for those cases will follow.
Swift SVN r2470
and derived) so they can be stored within the generic parameter list
for use 'later'.
More immediately, when we deduce arguments for a polymorphic function
type, check that all of the derived archetypes conform to all of the
protocol requirements, stashing that protocol-conformance information
in the coercion context (also for use 'later'). From a type-checking
perspective, we now actually verify requirements on associated types
such as the requirement on R.Element in, e.g.,
func minElement<R : Range requires R.Element : Ordered>(range : R)
-> R.Element
Swift SVN r2460
base type (e.g., the archetype type, when we're in a generic function)
used to refer to that operator as a member, e.g., given
func min<T : Ord>(x : T, y : T) {
if y < x { return y } else { return x }
}
'<' is found in the Ord protocol, and is referenced as
archetype_member_ref_expr type='(lhs : T, rhs : T) -> Bool' decl=<
(typeof_expr type='metatype<T>'))
using a new expression kind, TypeOfExpr, that simply produces a value
of metatype type for use as the base.
This solves half of the problem with operators in protocols; the other
half of the problem involves matching up operator requirements
appropriately when checking protocol conformance.
Swift SVN r2443
type substitution for a nested type reference (Foo.Bar.Wibble) whose
substituted parent reference (Foo.Bar) yields an archetype can simply
look for the appropriate nested type in the archetype.
This allows us to eliminate the hideous ASTContext::AssociatedTypeMap
and simply the archetype builder.
Swift SVN r2438
builder. For this to work, the 'parameter' used to seed the archetype
builder is the 'This' associated type, which implicitly conforms to
the protocol. All other archetype assignments flow from that
archetype.
In the same vein, when faking a polymorphic function type for an
operator found within a protocol, we only need to substitute for the
'This' associated type. The rest are derived due to the implicit
requirement that 'This' conforms to its protocol.
Finally, because archetype assignment within protocols occurs during
type-checking, and that archetype assignment may visit any protocol
visible in the translation unit, we need to validate the types used in
archetype assignment for *all* protocols before attempting archetype
assignment on any one protocol. Thus, perform this type validation
before the main declaration type-checking phase.
Swift SVN r2436
representation for the nested type:
- If the type is nested within a deducible generic parameter type,
build it as a nested type of that generic parameter type. (The
terminology is bogus)
- Otherwise, look for the member type of the given name and build a
reference to it.
Swift SVN r2426
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
