Using "T" as the contextual type, either for an implicit conversion
(in the coercion case) or as a downcast (for the checked-cast case),
opens up more type-inference opportunities. Most importantly, it
allows coercions such as "1 as UInt32" (important for
<rdar://problem/15283100>). Additionally, it allows one to omit
generic arguments within the type we're casting to.
Some additional cleanup to follow.
Swift SVN r10799
Similar to the T -> U? conversion, allow T? to be converted to U? through a bind-convert-inject chain. Naively adding this conversion creates ambiguities in the type checker, opening up multiple paths to the same solution in certain cases, so add a a special case to the solver that avoids introducing the conversion if a solution is already available by other means. (Doug figured out that part; thanks Doug!)
This still introduces a regression in test/Constraints/optional.swift, rendering a call ambiguous when overloaded on argument types. <rdar://problem/15367036>
Swift SVN r9857
The "conversion" constraint was far too loose, because we don't want
to permit arbitrary conversions on the left-hand side of the
'.'. Conformance constraints aren't correct either, because an
existential that does not conform to itself can still be used on the
left-hand side of a '.', so we introduce a new kind of constraint for
this.
Swift SVN r9630
The constraint solver was eagerly applying the T -> U? conversion
rule, which only succeeds when T is convertible to U. Thus, we would
reject valid code where T has a user-defined conversion to
U?. Instead, introduce a disjunction conversion to try either T -> U?
by converting T to U or via a user-defined conversion.
Most of this is infrastructure for the introduction of constraint
restrictions, which specify that a particular constraint (say, a
conversion constraint) should only try a single direct path:
scalar-to-tuple, value-to-optional, user-defined, etc. Each term in the
disjunction created for the T -> U? case is restricted to a particular
conversion rule, so that checking it does not create another
disjunction.
Keep track of the constraint restrictions we used within a given
solution, so that we can replay those steps during the application
phase. There is a bunch of inactive code here at the moment, which
will become useful as we start creating disjunctions for other
ambiguous conversions.
Swift SVN r9318
Overload bindings constraints bind a given type to a specific overload
choice. This is a step toward moving overload sets into normal
disjunction constraints.
Part of the work here is to eliminate the constraint system's
dependence on OverloadSet, which will be going away in favor of a
disjunction constraint.
Swift SVN r9209
