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.
To be able to infer base type in situations like:
```swift
func foo<T: P>(_: T) {}
foo(.bar)
```
Type variable used for a base type of the chain has to be allowed
to infer types from contextual protocol requirements e.g. `T: P`
in our example.
If the completion loc was in a trailing closure arg, it only makes sense to
ignore later missing args if they have function type, as there's no way for the
user to complete the call for overload being matched otherwise.
Also fix a bug where we were incorrectly penalizing solutions with holes that
were ultimately due to missing arguments after the completion position.
Resolves rdar://problem/72412302
Rename `openUnboundGenericTypes` to `convertInferableTypes`. In addition to unbound generics, this method also converts placeholder types to fresh type variables.
Previously l-value binding would be paired with discovered r-value
one but that is not necessary and can cause issues with ranking
since there is no way to filter this "fallback" binding from the
set.
Since there is a conversion from `() -> T` to `() -> Void` for closures,
solver has to attempt a `Void` when other bindings (inferred from the body)
have failed.
Let's try it post factum instead of adding `Void` fallback to the
binding set after every discovered supertype binding. Old scheme
wouldn't work in incremental mode anyway because it's possible to
find a subtype binding (which makes it clear that body has to have
a result type) after a supertype and end up attempting `Void` although
it would be incorrect.
If member type is unknown (determined to be a hole) `applicable function`
of any kind or `overload choice` cannot delay attempting it because doing
so would allow solver to make forward progress.
Currently `isLiteralCoveredBy` only checks for top-level type variable or hole.
That check has to be sunk down so it could be used after optionality is stripped
away (when possible), otherwise bindings like `$T0?` are (incorrectly) determined
to cover literal requirements (because conformance check always succeeds when
attempted on a type variable).
Using existing binding with updated type would result in incorrect
behavior in incremental mode since when "originating" (new) constraint
gets retracted it would leave a stale binding behind.
Currently the pattern is to collect the type variables and then unique
them. Instead of asking clients to do uniquing, let's just accept a set
as an argument.
Any constraints which would previously cause binding inference to
fail should instead delay associated type variable and preserve
all of the collected information.
This is vital for incremental binding computation that cannot
re-introduce constraints after "failure" because it's too expensive.
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.
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.
One more step towards incrementality of binding inference. Instead of
trying to determine literal protocol coverage during finalization
of the bindings, let's do that as soon as new bindings and/or literal
protocol requirements are discovered.
Literal protocol requirements are handled differently from other
protocols, they require additional contextual information (such
as coverage, direct/transitive distinction), and participate in
binding inference (could be turned into default bindings).
The only possible default which could satisfy both protocols is
`Double`, otherwise it has to be some custom type which conforms
to both protocols. Either way it's best to leave `ExpressibleByFloatLiteral`
in place to get to `Double` faster or make sure that custom type
conforms to it even if it would later fail `ExpressibleByIntegerLiteral`
conformance, at least that wouldn't introduce any unviable bindings.
Since `ExpressibleByNilLiteral` doesn't have a default type,
there is no need to track it in the set of protocols that could
produce defaultable bindings if not "covered" by existing bindings.
Let's keep defaults separate from direct and transitive bindings,
that would make it easier to handle them in incremental model.
Instead of generating bindings for defaults and adding to the main
set, let's allow producer to choose what to do with them once type
variable has been picked for attempting.
