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
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
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
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
introduce the generic type parameters (which are simply type aliases
for a to-be-determined archetype type) into scope for name
lookup. We can now parse something like
func f<T, U : Range>(x : T, y : U) { }
but there is no semantic analysis or even basic safety checking (yet).
Swift SVN r2197
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
type is either a protocol type or a protocol composition type. The
long form of this query returns the minimal set of protocol
declarations required by that existential type.
Use the new isExistentialType() everywhere that we previously checked
just for ProtocolType, implementing the appropriate rules. Among other
things, this includes:
- Type coercion
- Subtyping relationship
- Checking of explicit protocol conformance
- Member name lookup
Note the FIXME for IR generation; we need to decide how we want to
encode the witnesses for the different protocols.
This is most of <rdar://problem/11548207>.
Swift SVN r2086
classes, with the same syntax as we have on protocols. This
inheritance specifies explicit conformance to a protocol.
Later, we can allow a class definition to have a single class type
within this list, when we introduce class inheritance.
Swift SVN r1862
from a protocol to a protocol it inherits. This is a far simpler
operation that the general type-erasure expression, so generate this
AST when we can.
Swift SVN r1813
protocol Document { var title : String }
protocol Versioning { func bumpVersion() }
protocol VersionedDocument : Document, Versioning { }
This commit covers the basic functionality of protocol inheritance, including:
- Parsing & AST representation
- Conforming to a protocol also requires conforming to its inherited
protocols
- Member lookup into a protocol also looks into its inherited
protocols (results are aggregated; there is no name hiding)
- Teach ErasureExpr to maintain lvalueness, so we don't end up
performing a silly load/erase/materialize dance when accessing
members from an inherited protocol.
Swift SVN r1804
