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
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
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
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
protocol conformance types, e.g., 'protocol<P, Q>'. A few things
people *might* want to scream about, or at least scrutinize:
- The parsing of the '<' and '>' is odd, because '<' and '>' aren't
tokens, but are part of the operator grammar. Neither are '>>',
'>>>', '<>', etc., which also come up and need to be parsed
here. Rather than turning anything starting with '<' or '>' into a
different kind of token, I instead parse the initial '<' or '>'
from an operator token and leave the rest of the token as the
remaining operator.
- The canonical form of a protocol-composition type is minimized by
removing any protocols in the list that were inherited by other
protocols in the list, then sorting it. If a singleton list is
left, then the canonical type is simply that protocol type.
- It's a little unfortunate that we now have two existential types
in the system (ProtocolType and ProtocolCompositionType), because
many places will have to check both. Once ProtocolCompositionTypes
are working, we should consider whether it makes sense to remove
ProtocolType.
Still to come: name lookup, coercions.
Swift SVN r2066
using the term "unresolved" in expressions for a while, and it fits
for types better than "dependent type."
The term "dependent type" will likely come back at some point to mean
"involves an archetype".
Swift SVN r1962
archetypes. Use this substitution when checking the
variable/function/subscript witnesses during protocol conformance.
This allows us to check the conforms-to relationship for the Range
protocol as we want to express it.
Swift SVN r1945
wrap it in an 'id' type in the standard library.
Also fix a bug noticed by inspection where initWithTake for
function types wasn't entering a cleanup for the taken value.
This probably doesn't matter for existing possibilities, but
it's potentially important under exceptions.
Swift SVN r1902
This is <rdar://problem/10217868>. Apparently I'm using Lion's
libc++ headers somehow, which I should probably fix; but since
the use of shared_ptr is just a hack until DenseMap supports
move-only types, I don't feel bad about changing it to a different
hack that avoids shared_map altogether.
Swift SVN r1897
generic over the type of the base. By "generic" I mean that it's
looked up by prepending the word "Slice" to the name of the base
type.
Swift SVN r1464
and is just an unmanaged pointer. Also, introduce a basic swift.string type.
This is progress towards rdar://10923403 and strings. Review welcome.
Swift SVN r1349
type with one or more elements of dependent type. Previously, an
expression such as (x, 5) would have the (unstructured) dependent
type, limiting our ability to type-check the subexpression 'x'
early. Now, if 'x' has type 'int' (for example), this expression will
now have the type (int, <<unstructured dependent type>>).
Extend coercion of a tuple to tuple type to handle coercion to
(structured) dependent tuple types, coercing element-by-element. This
code is very lightly tested and may still need to be restructured.
Swift SVN r1294
in favor of a single-element non-canonical TupleType) broke the type
system, in that supposed sugar (the TupleType) supported a different
set of operations from the canonical type. For example, a
single-element unlabelled tuple type supports elementwise projection
(foo.$0), but the underlying element does not (or supports it
differently).
The IR-gen failure was due to a very related problem: IR-gen
was not updated to reflect that a single unlabelled tuple element
is the same type as its element type, and therefore it was giving
different representations to these types ({ %foo } and %foo,
respectively), which broke widespread assumptions.
The removal of ParenType was done in pursuit of an AST invariant
that's not actually particularly interesting in the first place
and which, furthermore, is problematic to attain.
Swift SVN r1182
it is now a single element TupleType(x). In order to preserve sane behavior,
we force grouping parens to be non-canonical and have them desugar down to
their underlying element type.
This does cause an IRGen testcase failure that looks like it was just working
accidentally before (though I don't really understand what is going on). I
filed rdar://10967479 to track it.
Swift SVN r1146
- introduce the concept of qualifiers on l-value types
- teach overload resolution and coercion how to drop explicitness
- require explicitness on normal [byref] arguments
- make 'this' [byref(implicit)]
- special-case '&' as a unary operator in the parser to make it
produce an expression which type-checks as turning implicit l-values
into explicit ones.
Obvious missing pieces:
- updating LangRef
- we should really complain about ever trying to rvalue-convert an
explicit l-value
- maybe qualification should play a part in overload resolution
- we should diagnose attempts to declare unary '&' operators
- there's a test case in expressions.swift which suggests my logic is
slightly off
But I am out of time, and these will have to wait.
Swift SVN r1119
