Despite being otherwise disconnected from the
constraint system, it's possible for it to affect
how we type-check tuple matches in certain cases.
This is due to the fact that:
- It can have a lower type variable ID than an
opened generic parameter type, so becomes the
representative when merged with it. And because it
has a different locator, this can influence
binding prioritization.
- Tuple subtyping is broken, as it's currently a
*weaker* relationship than conversion.
Therefore, temporarily restore this bit of logic
for language versions < 6. If possible, we should
try and fix tuple subtying in Swift 6 mode to not
accept label mismatches, so that it's not more
permissive than tuple conversion.
rdar://85263844
Closure result type or generic parameter associated with such a location
could bw inferred from a body of a multi-statement closure (when inference
is enabled), so we need to give closure a chance to run before attemtping
a hole for such positions in diagnostic mode.
If a type variable has a subtype binding which came from a conversion/subtype/equality
constraint to a struct or enum (expect to `AnyHashable`, `Unsafe{Mutable}RawPointer`),
attempt it early because that type is the only choice which is not going to fail such
constraint.
For example, in cases like `$T argument convertible to Int` type variable could
only be bound to `Int`, `Int!`, or `@lvalue Int` to satisfy that constraint, so
it would make sense to attempt to bind it to `Int` early if it doesn't represent
a result of a member lookup (that's how IUO and/or `@lvalue` could be inferred)`
and doesn't have any direct disjunction associated with it e.g. for coercion or
optional matching.
Caching the result here feels a little overkill as
it's only useful for one protocol, and the
`TypeChecker::getDefaultType` computation is
cached by the request evaluator.
It's always been the case that partial solutions introduce
some storage duplication when applied back to the constraint
system to form a more complete solution with outer context,
but the constraint systems used to be small before
introduction of result builders (and now multi-statement
inference), which make the duplication more visible.
FunctionInput relies on being able to represent
parameter lists as tuples, which won't be possible
once parameter flags are stripped from tuple types.
FunctionResult is reasonable, but is currently
unused.
It's similar to disjunction constraint but represents an "and"
relationship between its elements instead of "or", so all of the
elements have to produce a solution for conjunction constraint
to be considered solved successfully.
If underlying type of an optional chain has been marked as a hole,
e.g. due to a reference to an invalid or missing member, let's
propagate that information to object type of an optional that
represents a result of an optional chain.
Resolves: rdar://80941497
* [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.
