Currently bindings where inferred on every `bindTypeVariable` call,
but that's wasteful because not all binds are always correct. To
avoid unnecessary inference traffic let's wait until re-activated
constraints are simplified and notify binding inference about new
fixed type only if all of them are successful.
We were previously completely skipping the "best" solution filtering the solver
does to make sure we didn't miss any non-best but still viable solutions, as
the completions generated from them can make them become the best solution. E.g:
struct Foo { let onFoo = 10 }
func foo(_ x: Int) -> Int { return 1 }
func foo<T>(_ x: T) -> Foo { return Foo() }
foo(3).<here> // the "best" solution is the one with the more-specialized foo(x: Int) overload
In the example above we shouldn't remove the solution for foo(x: T) even though
there is a single "best" solution (`foo(x: Int)`) as picking a completion
result generated from it (`onFoo`) would make the foo(x: T) overload the best
and only viable solution.
Completely skipping this filtering as we were previously doing is overkill
though and adversely affects performance. E.g. it makes sense to filter out
and stop exploring solutions with overload choices for foo that required fixes
for missing arguments if there is another solution with an overload choice that
didn't require any fixes.
This patch restores best solution filtering during code completion and instead updates
the compareSolutions function it compare solutions based purely on their fixed score.
Resolves rdar://problem/73282163
when it has property wrapper parameters.
The property wrapper type will be replaced with either the wrapped-value
or projected-value type, depending on the argument label/parameter name,
and CSApply will build a thunk to construct the property wrapper and call
the function.
`PotentialBindings` lost most of its responsibilities,
and are no longer comparable. Their main purpose now
is binding and metadata tracking (introduction/retraction).
New `BindingSet` type is something that represents a set
of bindings at the current step of the solver.
Instead of requiring result type of the member to conform to declaring protocol,
as originally proposed by SE-0299, let's instead require `Self` to be bound to
some concrete type in extension that declares a static member.
This would make sure that:
1. Members are only visible on a particular type;
2. There is no ambiguity regarding what base of the member chain is going to be.
The first type represents a result of an unresolved member chain,
and the second type is its base type. This constraint acts almost
like `Equal` but also enforces following semantics:
- It's possible to infer a base from a result type by looking through
this constraint, but it's only solved when both types are bound.
- If base is a protocol metatype, this constraint becomes a conformance
check instead of an equality.
Rename `openUnboundGenericTypes` to `convertInferableTypes`. In addition to unbound generics, this method also converts placeholder types to fresh type variables.
Create a new namespace - `swift::constraints::inference` and associate
`PotentialBinding` with it. This way it would be possible for constraint
graph to operate on `PotentialBinding(s)` in the future.
Currently potential bindings are stored in a vector (`SmallVector`)
and every call has to pass additional set of unique types to
inference methods to unqiue the bindings. Instead let's merge
these two together and use `SetVector` for binding storage,
which would also be great for incremental mode that can't
pass additional sets around.
for arithmetic operators.
Only sort overloads that are related, e.g. Sequence
overloads. Further, choose which generic overloads
to attempt first based on whether any known argument types
conform to one of the standard arithmetic protocols.
disjunction choice that does not introduce conversions, check to see
if known argument types satisfy generic operator conformance requirements
early, and skip the overload choice if any requirements fail.
This helps the solver avoid exploring way too much search space when
the right solution involves a generic operator, but the argument types
are known up front, such as `collection + collection + collection`.
Doing so streamlines access to the information associated with literal
protocol requirements and allows to add more helpers.
Also cache default type in the struct itself for easy access.
