Previously, the constraint graph only represented type variables that
were both unbound and were the representatives within their respective
equivalence classes. To achieve this, each constraint was fully
simplified when it was added to the graph, which is a fairly expensive
process. This representation made certain operations---merging two type
variables, replacing a type variable with a fixed type, etc---both
hard to implement and hard to reverse, forcing us to rebuild the
constraint graph each time.
Now, add all type variables to the graph (including those with fixed
type bindings and non-representatives) and add constraints without
simplification. Separately track the equivalence classes of each type
variable (in the representative's node) and adjacencies due to type
variables showing up in the fixed type bindings of other type
variables. Although not yet implemented, the merging and type variable
replacement operations are far easier to implement (and more
efficient) with this representation, and are also easier to undo,
making this a step toward creating and updating a single consistent,
global constraint graph rather than re-creating a constraint graph
during each solver step.
Performance-wise, this is a 4% regression when type-checking the
standard library. I expect to make that up easily once we switch to a
single constraint graph.
Swift SVN r10897
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
