This disappeared in the rework of IUOs but is needed when we have
multiple potential solutions involving different sets of overloads or
type bindings.
Fixes rdar://problem/37475971.
Many (perhaps most?) calls to createTypeVariable explicitly pass 0 for
options. This change just defaults the parameter to 0 and removes all
the explicit 0's in the code.
Don't try to short-circuit disjunctions if one of the choices
produced tuple-to-tuple conversion since that doesn't mean
that there are no other choices out there.
Don't attempt to store literal bindings directly to `PotentialBindings`
since they might get superseded by non-literal bindings deduced from
other constraints, also don't attempt to check literal protocol conformance
on type variables or member types since such types would always end-up
returning trivial conformance which results in removal of viable literal types.
Resolves: rdar://problem/38535743
Such overloads are not going to result in viable solutions anyway,
so it makes sense to attempt them only if solver failed to deduce
proper solution.
Helps to improve type-checking performance of operators which have
multiple unavailable overloads for compatibility reasons.
The current implementation isn't really useful in the face of generic
overloads. It has never been enabled by default, and isn't useful to
keep around if it is disabled. If we ever want to bring it back,
we know where to look!
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
If a prior solution required fixes, do not skip generic
overloads. They might result in a fix-free solution.
Suggested by @xedin as an adjunct to a similar change I made for
short-circuiting disjunctions.
There are cases where disjunctions created for IUOs can be solved with
the Optional choice if a fix is applied. We do not want to stop with
this solution as we may be able to solve the constraint system without
a fix by selecting the non-Optional side.
I have opened a JIRA, SR-6626, to investigate one small regression in
diagnostics with this change.
Instead of binding collection types directly let's try to
bind using temporary type variables substituted for element
types, that's going to ensure that subtype relationship is
always preserved.
Resolves: rdar://problem/35541153
There are situations where we know equivalence relationship between
multiple disjunctions, let's prune dependent choice space based on
choice picked for the parent disjunction.
Resolves: rdar://problem/35540159
Consider different overload choices for the same location in evaluation
order, this makes overload resolution more predictable because it's going
to follow expression bottom-up, that prevents situations when some
expressions are considered ambigious because choices taken further up
equate the score, instead each level is given distinct weight
based on evaluation order.
Resolves: rdar://problem/31888810
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
If the best bindings we could get on the current step are bindings
to literal type without any other type variable involved, let's try
to attempt them right away, that should help to prune search space.
When dealing with explicit coercions apply their conversions
early to avoid searching for solutions with incorrect types,
and therefore prune search space.
Move disjunction selection logic one level up from the `solveSimplified`
which allows to simplify its logic and avoid collecting disjunctions
multiple times for each solver step.
Sort constraint components/buckets based on how many disjunctions
they have, that helps to prune some of the branches with incorrect
solutions early which limits overall depth of the search.
Resolves: SR-4714
Limit the scope of the performance hacks which currently exist in the
solver even further by disallowing it to skip generic overlaods or stop
in case when previous solutions involve unavailable overloads, which
otherwise might lead to producing incorrect overall solutions.
While shrinking we have to allocate containers for the reduced domains
for some of the candidates, it's currently done using permanent arena
of the `ASTContext` allocator. This patch changes candidate solver to
use arena associated with the parent constraint system, which significantly
limits lifetime of domain containers.
This was initially added to avoid "expression was too complex" in a
case where we were not previously reporting it for -swift-version 3
but should have been. In retrospect this seems misguided since
although we would not like to regress on "too complex" expressions, we
really don't want to silently continue in the cases where we decide an
expression is "too complex", but where we have a solution that we
could use. It's better to fail.
When trying to identify candidates for shrinking we are missing the case
when apply expression is a source of the assignment operator, which leads
to incorrect results in some situations, because shrink is going to miss
some required contextual information about assignment.
Resolves: rdar://problem/33190087
Split out the code for selecting potential bindings into a separate file
as a first step before refactoring it for improved clarity and ease of
modification.
In some situations e.g. while trying to shrink domains of the type
variables before attempting search, use a flag to tell constraint
system to retain all of the viable solutions otherwise solver could
loose some of the information required to produce complete solution.
Resolves: rdar://problem/32726044
By default, end expression type checking after the elapsed process time
is more than 60 seconds for the current expression. This threshold can
be overridden by using -solver-expression-time-threshold=<seconds>.
Resolves rdar://problem/32859654
Calls involving single trailing closure arguments require special
handling because we don't have as much contextual information
about function/argument types as in with regular calls, which means
that diagnosing such situations only by `visitApplyExpr`
yields subpar results.
Resolves: SR-4836.
Track outcomes of `conformsToProtocol` calls in `simplifyConformanceConstraints`
to be able to validate conformances when solution is formed to avoid returning
solutions with nominal types with invalid conformances to protocols.
There is a short-circuiting hack in the constraint solver that speeds up
solving, but isn't generally sound. If we allow unavailable decls to be
considered "favored", this can fire and result in our choosing a
solution that involves the unavailable decl where other solutions exist.
Fixes rdar://problem/32570734.
Restrict skipping of the generic overloads only to the situations
when non-generic solution doesn't have any restrictions/fixes, because
there is a possibility that generic overload could produce a better
solution.
Resolves: rdar://problem/32204609.
