* [TypeResolver][TypeChecker] Add support for structural opaque result types
* [TypeResolver][TypeChecker] Clean up changes that add structural opaque result types
Allow type variable binding producer to record types as they
are being produced. Otherwise it could be possible to re-discover
already explored types during `computeNext()` which leads to
duplicate bindings e.g. inferring fallback `Void` for a closure
result type when `Void` was already inferred as a direct/transitive
binding.
When inference is determining bindings of a type variable that represents
an overload set (e.g. member or operator reference), let's not consider
it as delayed due to presence of `ApplicableFunction` constraint since
argument/result type inference depends on overload set but not vice versa.
Resolves: rdar://78917861
This constraint is used to enforce ordering of inference and provide
a starting point for inference of base based on associated generic
constraints. It's an `Equals` constraint with additional semantics
that only apply to unresolved members, which means that there are
no (other) adjacent variables in this case.
Resolves: rdar://78425221
It's not permitted to use `PartialKeyPath` type to resolve a key path
expression, because that type is intended to be a type-erased version of
a fully resolved `KeyPath` type.
In situations where contextual type is a partial key path (e.g. parameter
type is a partial key path), let's replace it with a `KeyPath` type that
is a subtype of `PartialKeyPath` and allow value inference to happen.
Resolves: SR-5667
Resolves: rdar://32365183
A type representing a closure expression is always bound to its
"inferred" type based on the body, so contextual bindings just
serve as a trigger to "resolve" a closure. Let's not attempt any
subtype/supertype inference for a type variable representing a
closure since if "direct" bindings have failed, it wouldn't be bound
to such types regardless.
Resolves: rdar://problem/77022842
Conformance constraints could be transferred through conversions,
but that would also require checking implicit conversions
such as optional and pointer promotions for conformance is the
type itself doesn't conform, for that let's add a special constraint
`TransitivelyConformsTo`.
Nothing besides static member refs on protocols feature is currently
using transitive protocols, so instead of trying to infer them on every
step let's do that only for base type of a dot-syntax reference when
there are no other bindings for it.
Currently inference logic only checked direct equivalence class members
associated with a "work-in-progress" type variable, but each member can
have local equivalences as well that need to be accounted for.
Resolves: rdar://75978086
Always prefer binding to `Double` over `CGFloat` if possible
since there is an implicit conversion between them and attempting
both could lead to ambiguities.
If member has been bound before the base and the base was
incorrect at that (e.g. fallback to default `Any` type),
then we need to re-activate all of the constraints
associated with this member reference otherwise some of
the constraints could be left unchecked in inactive state.
This is especially important for key path expressions because
`key path` constraint can't be retired until all components
are simplified.
Resolves: SR-13364
Resolves: rdar://66706980
Resolves: rdar://74711236
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.
Since equivalence class shares protocols, let's copy-initialize
transitive requirement sets because move would result in slots
with null pointers if equivalence class is bigger than just one member.
Resolves: rdar://74723323
Previously bindings were inferred only during solving but now they
are inferred as soon as something changes in the constraint graph,
so the hack that dropped `noEscape` bit from function type when
inferred for generic parameter should be allowed during constraint
generation as well.
`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.
- `ConstraintSystem` is now referenced as a member of `PotentialBindings`;
- Literals and defaults are no longer added to the `Bindings` list, so we
to add a new method `hasViableBindings` to make sure that protocol types
are added only when there are no other bindings.
If it has been established that member found via static member
lookup on protocol metatype doesn't have correct result type,
chain's result type the should be treated as a hole.
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
