Introduce `TypeBinding` interface with a single `attempt` method
which is useful to encapsulate specific binding logic used for
attempting disjunction choices and type variable bindings under
a single interface. This makes it easier to unify top-level logic
responsible for binding enumeration.
It should also make it possible to introduce unified binding producer
interface in the future.
Currently `allowFreeTypeVariableBindings` flag has to be passed all
the way down from top-level `solve` call to `finalize` that forms
(partial and complete) solutions. Instead of doing that, let's just
make it a part of the solver state, which is already present
throughout whole solver run.
Encapsulate most of the logic related to new binding generation
and iteration into `TypeVarBindingGenerator`. `tryTypeVariableBindings`
is only responsible for attempting bindings and recording results.
One more step towards iterative solver.
* Move logic to ensure that r-value type var would get r-value type to `PotentialBindings`;
* Strip uncessary parens directly when creating `PotentialBinding`;
* Check if the binding is viable before inclusion in the set, instead of filtering it later;
* Assert that bindings don't have types with errors included in the set.
Instead of passing a set of choices, locator and other flags to
`solveForDisjunctionChoices` directly, let's wrap all that information
into "disjunction" iterator which returns `DisjunctionChoice`s
directly.
Since this logic is tightly coupled to constraint, it makes sense
to move just there, also it's easier to re-use it elsewhere since
it doesn't have to be `private` anymore.
Replace the GenericTypeResolver type hierarchy with TypeResolution,
which more simply encapsulates the information needed to resolve
dependent types and makes explicit those places where we are
using resolution to contextual types.
Add an assert which verifies that all of the disjunction
choices has the same type variable on the left-hand side.
Based on that fact, refactor `selectBestBindingDisjunction`
to only check first choice to find suitable "bind" disjunctions
to favor.
TypeResolutionFlags is overly complicated at the moment because the vast
majority of flag combinations are impossible and nonsensical. With this
patch, we create a new TypeResolverContext type that is a classic enum
and far easier to reason about. It also enables "exhaustive enum"
checking, unlike the "flags" based approach.
This is a legacy holdover from when tuple types had default
arguments, and also the constraint solver's matching of function
types pre-SE-0110.
Well, move the last live usage to CSDiag, where it can die a slow
painful death over time. The other usages were not doing anything.
This is helpful in experimenting with constraint solver changes that
might help us remove some of these unsound options. It's not ever mean
to be enabled, but if we're able to remove the things guarded by the
option we can eventually remove the option.
so that they must result in an optional type.
Add constraint locator path for identifying constraints/variables that are part of the convert type passed into the system.
Polling the timers used to measure “expression too complex” is not *that*
cheap. When the constraint solver is doing a lot of work, the overhead can
add up. Reduce the number of places where we poll the timer down to
main decision points (i.e., before exploring a disjunction or binding a
new type variable), taking the timing overhead from ~3.7% —> ~1.7%.
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.
Rather than avoiding short-circuiting if we've selected any
unavailable overload or applied any fixes as part of the previously
found solution, only avoid short-circuiting if selecting those
overloads or applying those fixes was a direct result of the
disjunction choice we were visiting in the previously found solution.
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
I am reverting the effect of 6fa403dc7d
in 7fd052efd8, and removing this
optimization was dependent on that change in ordering.
This reverts commit c29f660652.
Implementation is as follows: In `preCheckExpression` try to
detect if there is `T(literal)` call in the AST, replace it with
implicit `literal as T`, while trying to form type-checked AST,
after constraint solving, restore source information and drop
unnecessary coercion expression.
Resolves: rdar://problem/17088188
Resolves: rdar://problem/39120081
Resolves: rdar://problem/23672697
Resolves: rdar://problem/40379985
