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
This currently-untestable code allows updates to the constraint graph
when a same-type constraint causes two type variables to be
unified. Additionally, it handles the removal of a constraint from the
constraint system, e.g., if it is solved.
Swift SVN r10716
At each solution phase, construct a constraint graph and identify the
smallest connected component. Only solve for the variables in that
connected component, and restrict simplification to the constraints
within that connected component. This reduces the number of
visited-but-not-simplified constraints by ~2x when type-checking the
standard library.
Performance-wise, this is actually a regression (0.25s/8% when parsing
the standard library), because the time spent building the constraint
graph exceeds the time saved by the optimization above.
The hackaround in the standard library is due to
<rdar://problem/15168483>. Essentially, this commit changes the order
in which we visit type variables, causing the type checker to make
some very poor deduction choices.
The point of actually committing this is that it validates the
constraint graph construction and sets the stage for an actual
optimization based on isolating the solving work for the different
components.
Swift SVN r10672
This implements an offline algorithm for connected components. We
could use an online algorithm, which would be slightly more efficient
in the case where we always require the connected components, but such
algorithms don't cope with edge removals very well.
Still just a debugging tool!
Swift SVN r10663
