statements. The approach is fairly simple: generate constraints for
both the destination and source expressions, then turn the destination
type into a type containing only rvalues and convert the source
expression to that type.
Swift SVN r2925
using archetypes so that, e.g., an archetype T that conforms to
Ordered can be compared with <. Requires the introduction of
'archetype' constraints, so that we don't run amok and allow the use
of operators in protocols for *any* type that meets the requirements
of the protocol. This may change later, with default implementations,
of course.
The egregious hack introduced in Char.isSpace() works around known,
massive performance problems with the solver's exploration of the
state space. In this case, we have 6 instances of ==, each of which
has 18 overloads, for a large state space. However, we compound the
problem significantly by trying many possibilities for the ~30 type
variables in each state, rather than concluding quickly (as we should)
that most of those branches don't make sense.
Swift SVN r2922
constraint solver produces multiple solutions. The criteria for "best"
are fairly simple: we compare the bindings for each type variable
bound in both solutions:
- If the binding in the first solution is a subtype of the binding
in the second solution, but not vice-versa, the first solution is
at least as good as the second
- If the type variable has a literal constraint on it, and the bound
type in the first solution matches the default literal type for
that literal kind, the first solution is as good as the second.
From there, we follow the obvious rules for picking a winner: if some
of the type variables in the first solution are as good as the same type
variables in the second solution, but none of the type variables are
worse, then the first solution is better.
We can now type-check "1 + 2.0". Take *that*, TypeCheckCoercion.cpp.
Swift SVN r2894
T(x)
where T is the name of a type. This syntax either coerces 'x' to the
type T or, failing that, enumerates the constructors of T and invokes
one of them.
Note that, syntactically, this coercion is syntactically identical to
a function application
f(x)
We distinguish these cases with a simple, syntax-based scheme: if the
'function' subexpression of the application can be trivially
determined to have metatype type, then we consider this a
construction. Otherwise, we assume that it's a function
application. This disallows some crazy coercions---e.g., those that
involve overloaded variables of metatype type---but should feel fairly
intuitive, and it keeps the constraint systems simpler.
Swift SVN r2802
to a type, without removing the lvalueness of the replacement
type. Keeping the lvalueness is important when referring to a
declaration, because that reference might be an
lvalue. Properties/subscripts are working better now.
Swift SVN r2796
constraint-based type checker, include the body of the explicit
closure within the set of constraints. This allows type information to
flow from the body expression, so that we can type-check, e.g.,
map(new Int[N], { $0.toString() })
to a String[] without context information. Fixes <rdar://problem/11229738>.
Swift SVN r2794
conversions. We limit the relationship between the result of the
conversion and the actual expected type to a subtyping relationship,
which effectively limits us to applying a single user-defined
conversion function (rather than a chain of such conversions).
Later, we can consider extending this to a chain of conversion
functions, but that will require us to cope with cyclic conversions
and minimizing conversion sequences (e.g., if A -> B -> C and A -> C
are both possible, we should prefer A -> C).
Swift SVN r2730
difference is that a concrete type's conformance to an existential
type is considered a conversion (but not a subtyping). Relationships
between two existential types are (non-trivial) subtyping relationships.
Swift SVN r2718
system has been "solved", meaning that all type variables have been
bound to concrete types or are completely free. Add the solvedness of
a particular system to the debug output.
Start adding some simple test cases.
Swift SVN r2706
