Previously, retractFromInference() was the last step in
unbindTypeVariable(). This doesn't really make sense,
because bindTypeVariable() doesn't call introduceToInference();
its two callers do it later.
Start untangling this by splitting off introduceToInference()
into its own Change, but for now, record this change at the
incorrect place to maintain the same behavior as before.
I think the original idea was to elide `Array<$T>` if there is
a binding a resolved generic arguments i.e. `Array<Float>`, but
the check doesn't account for the fact that bindings could be
of different kinds and there are some implicit conversions that
could be missed if we remove the bindings.
For example, given the following constraints:
`Array<$T0> conv $T1`
`$T1 conv Array<(String, Int)>`
`$T0` can be a supertype of `Array<$T0>` and subtype of `Array<(String, Int)>`.
The solver should accept both types as viable bindings because the
`$T0` could be bound to `(key: String, value: Int)` and that would
match `Array<(String, Int)>` conversion.
Allow inferring type of `inout` from a pointer type
(or optional thereof) but delay the binding set because
it might not be complete and object type of `inout` could
also be an Array or C-style pointer type.
Placeholders propagate but we still can allow contextual inference,
to facilitate that the solver should consider `l-value object` constraint
to be solved and allow placeholders on "object" type.
This aims to help with cases like `_ = { x in x = 0 }` or `.test = 42`
which are currently supported because the member is eagerly bound to
an `@lvalue $T` during constraint generation.
Constraint generation uses a special pattern while generating
constraints for assignments to make sure that the source type
is convertible to r-value type of the destination.
`BindingSet::favoredOverDisjunction` needs to recognize this
pattern, where disjunction type variable is bound early, and
avoid prioritizing closure if it's connected to the "fixed type"
of the disjunction or risk losing annotations associated with
the member such as `@Sendable` or a global actor.
Resolves: rdar://131524246
Make sure `CouldNotInferPlaceholderType` can
produce a diagnostic for a `PlaceholderType`
locator element, and avoid emitting an extra
diagnostic for a placeholder type in an invalid
position.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
If both sides of an `OptionalObject` constraint are un-inferred, their
binding sets need to correctly reflect adjacency - a type variable
that represents optional would get "object" as an adjacency through
its potential binding (the binding is - "object" wrapped in a single
level of optional) and "object" type variable needs to get its parent
optional type variable added to its adjacency list explicitly.
Without this it would be possible to prematurely pick "object" before
its parent optional type variable.
Resolves: https://github.com/apple/swift/issues/73207
Resolves: rdar://126960579
Inference cannot be allowed in cases where both sides are type
variables and optional type is l-value capable because it results
in binding "optional" to an optional type and later discovering
a contextual type that is l-value optional i.e. if "optional type"
is resolved by selecting subscript overload.
Always marking generic parameter type variables as incomplete
is too aggressive. That was the way to make sure that they
are never attempted to eagerly, but really there are only a
couple of situations where that can cause issues:
```
1. Int <: $T_param
$T1 <: $T_param
2. $T2 conv Generic<$T_param>
$T2 conv Generic<Int?>
Int <: $T_param
```
Attempting $T_param before $T1 in 1. could result in a missed
optional type binding for example.
Attempting $T_param too early in this case (before $T2) could
miss some transitive bindings inferred through conversion
of `Generic` type.
If a type variable that represents a generic parameter is no longer
associated with any type variables (directly or indirectly) it's safe
to assume that its binding set is complete.
There's no good reason to permit them. Conformances like Copyable and
Sendable are pervasive, so it's as though we are permitting extensions
of `Any`. Until there's a good argument in favor of such extensions,
remove the capability now.
- Drop `mayHaveSuperclass` because it's too restrictive.
- Add logic to get superclass of existential and re-create
existential type with all of the protocol requirements.
If the underlying key path is not Sendable, the compiler generated
closure that captures the key path expression (as `{ [$kp$ = ...] in $0[keyPath: $kp$] }`)
cannot be marked as Sendable either.
Binding inference through a contextual root variable should include
marking contextual root and all of its adjacent variables as adjacent
to a key path root variable as well otherwise transitively inferred
bindings are ranked incorrectly.
Since generic arguments have to match exactly the inference could
be extended to transfer bindings through contextual root types if
they are sufficiently resolved (not delayed).
For example if key path expression is passed as an argument to
a parameter like `WritableKeyPath<$Root, $Value>` and `$Root`
is not yet bound but has a binding set of `{String}` its bindings
are transferable over to resolve the key path which would be
ultimately bound to the contextual type.
Follow-up to https://github.com/apple/swift/pull/70148
Just like with arrays it's advantageous to favor dictionary
literals over disjunctions to bind the elements together and
enable inference across elements and, as a consequence,
type pruning.
Resolves: rdar://119040159
If key path capability is not yet determined it cannot be favored
over a conjunction because:
1. There could be no other bindings and that would mean that
key path would be selected even though it's not yet ready.
2. A conjunction could be the source of type context for the key path.
Resolves: rdar://119055010
