Most of the use-cases of `gatherConstraints` require filtering
at least based on the constraint kind that caller is interested in,
so instead of returning unrelated results and asking caller to
filter separately, let's add that functionality directly to
`gatherConstraints`.
Since it's possible to find the same constraint through two different
but equivalent type variables, let's use a set to store constraints
instead of a vector to avoid processing the same constraint multiple
times.
Currently we have this non-optimal behavior in `contractEdges` where
for every type variable it gathers constraints for its whole equivalence
class before checking if any are "contractable", instead constraints
could be gathered/filtered once which removes a lot of useless work.
Improve situation around closure parameter/argument contractions
by allowing such action if it can be proved that none of the bindings
would result in solver attempting to bind parameter to `inout` type.
Resolves: rdar://problem/36838495
Currently edge related to the parameter bindings is contracted
without properly checking if newly created equivalence class has
the same inout & l-value requirements. This patch improves the
situation by disallowing contraction of the edges related to parameter
binding constraint where left-hand side has `inout` attribute set.
Such guarantees that parameter can get `inout` type assigned when
argument gets `l-value` type.
Resolves: rdar://problem/33429010
Presently subtype constraint is considered a candidate for contraction
via `shouldContractEdge` when left-hand side of the subtype constraint
is an inout type with type variable inside. Although it's intended to
be used only in combination with BindParam constraint assigned to the
same variable, that is actually never checked and contraction of subtype
constraint like that is invalid.
Resolves: rdar://problem/34333874
When gathering constraints for a type variable, we were gathering all of
the constraints for the members of the equivalence class, and then for
the adjacencies of the representative of the equivalence class, but not
from the adjacencies of other members of the equivalence class.
For example for:
#3 = $T3
#4 = $T4 equivalent to $T3
#5 = $T5 as $T4.Element
after binding $T3 we would collect the constraints related to $T3 and
$T4, but not $T5. The end result can be that we finish examining all
disjunctions and type bindings but still have inactive constraints in
the constraint graph, which is treated as a failure in the solver.
Fixes SR-5120 / rdar://problem/32618740.
The constraint graph models type variables (as the nodes) and
constraints (as the multi-edges connecting nodes). The connected
components within this (multi-)graph are independent subproblems that
are solved separately; the results from each subproblem are then
combined. The approach helps curtail exponential behavior, because
(e.g.) the disjunctions/type variables in one component won't ever be
explored while solving for another component
This approach assumes that all of the constraints that cannot be
immediately solved are associated with one or more type
variables. This is almost entirely true---constraints that don't
involve type variables are immediately simplified.
Except for disjunctions. A disjunction involving no type variables
would not appear *at all* in the constraint graph. Worse, it's
independence from other constraints could not be established, so the
constraint solver would go exponential for every one of these
constraints. This has always been an issue, but it got worse with the
separation of type checking of "as" into the "coercion" case and the
"bridging" case, which introduced more of these disjunctions. This led
to counterintuitive behavior where adding "as Foo" would cause the
type checking to take *more* time than leaving it off, if both sides
of the "as" were known to be concrete. rdar://problem/30545483
captures a case (now in the new test case) where we saw such
exponential blow-ups.
Teach the constraint graph to keep track of "orphaned" constraints
that don't reference any type variables, and treat each "orphaned"
constraint as a separate connected component. That way, they're solved
independently.
Fixes rdar://problem/30545483 and will likely curtain other
exponential behavior we're seeing in the solver.
Once we've bound a type variable, we find those inactive constraints
that mention the type variable and make them active, so they'll be
simplified again. However, we weren't finding *all* constraints that
could be affected---in particular, we weren't searching everything
related to the type variables in the equivalence class, which meant
that some constraints would not get visited... and we would to
type-check simply because we didn't look at a constraint again when we
should have.
Fixes rdar://problem/29633747.
In the constraint solver, we've traditionally modeled nested type via
a "type member" constraint of the form
$T1 = $T0.NameOfTypeMember
and treated $T1 as a type variable. While the solver did generally try
to avoid attempting bindings for $T1 (it would wait until $T0 was
bound, which solves the constraint), on occasion we would get weird
behavior because the solver did try to bind the type
variable.
With this commit, model nested types via DependentMemberType, the same
way we handle (e.g.) the nested type of a generic type parameter. This
solution maintains more information (e.g., we know specifically which
associated type we're referring to), fits in better with the type
system (we know how to deal with dependent members throughout the type
checker, AST, and so on), and is easier to reason able.
This change is a performance optimization for the type checker for a
few reasons. First, it reduces the number of type variables we need to
deal with significantly (we create half as many type variables while
type checking the standard library), and the solver scales poorly with
the number of type variables because it visits all of the
as-yet-unbound type variables at each solving step. Second, it
eliminates a number of redundant by-name lookups in cases where we
already know which associated type we want.
Overall, this change provides a 25% speedup when type-checking the
standard library.
In these cases, we should just go ahead and remove the redundant constraints:
- They don't help us derive a solution for the system
- Not doing so might leave "dangling" constraints that will make the system unsolvable
This eliminates the duplication of type variables that represent the member types of existing type variables. I'm unable to trigger this with a test case at the moment, but it becomes important when we begin to substitute type variables through protocol conformances.
Swift SVN r12971
Provides a 4% speedup type-checking the standard library. This
optimization brings the global constraint graph within 2% of the prior
solution, and prevents us from creating multiple constraint graphs per
constraint system, so flip the switch to always use the global
constraint graph.
Swift SVN r11003
Whenever we bind a type variable or merge two type variables, add
those constraints that could be affected to a worklist. Simplification
continues processing constraints in the worklist until the worklist is
empty.
This change reduces the number of constraints that we visit but can't
simplify by ~13x in the standard library, but this doesn't translate
into a performance win. More investigation is needed here.
Note that the worklist is only in use when we have a global constraint
graph, which isn't enabled by default yet.
Swift SVN r10936
Make the constraint graph into a scoped data structure that tracks the
changes that occur within a given scope, undoing those changes when
the scope is popped off the scope stack. The constraint graph's scopes
align with the constraint solver's scopes. Synchronize the solver's
constraint addition/removal operations with the constraint graph, and
improve our verification to make sure these stay in sync.
This is still a work in progress. Type checking the standard library
is about 5% slower with the per-constraint-system constraint graph
rather than building a new constraint graph each iteration *after*
simplification, and there are two intruiging test failures that appear
to be the constraint solver breaking its own invariants. Therefore,
this feature is off by default. See the ConstraintSystem constructor
for the one-line change to turn it back on.
Swift SVN r10927
Rather than building the constraint graph after simplification and
then never modifying it, build the constraint graph before
simplification and update it as simplification adds/removes
constraints. This is a step toward two separable performance goals:
(1) having a single constraint graph that evolves over the lifetime of
the constraint system, rather than building a new constraint graph at
each solver step, and (2) using the constraint graph to implement a
worklist traversal during simplification, so we only re-simplify those
constraints that might be affected by a choice the solver makes.
This behavior is currently optional with an ugly in-source flag
because while it works, it's a rather painful performance regression
that I don't want to subject everyone to. I'll turn it on for everyone
once it's a win, which should be after either (1) or (2) above is
implemented.
Swift SVN r10924
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
