We don't want to do that in general because injection should happen
only in one place but Void is special because it allows conversions
in that position.
Let's not perform $T? -> $T for closure result types to avoid having
to re-discover solutions that differ only in location of optional
injection.
The pattern with such type variables is:
```
$T_body <conv/subtype> $T_result <conv/subtype> $T_contextual_result
```
When `$T_contextual_result` is `Optional<$U>`, the optional injection
can either happen from `$T_body` or from `$T_result` (if `return`
expression is non-optional), if we allow both the solver would
find two solutions that differ only in location of optional
injection.
The original attempt to do this was reverted by https://github.com/swiftlang/swift/pull/77653
The problem is that the fix was too broad, I narrowed it down to
non-exact uses of stdlib collections that support upcasts.
PotentialBindings is part of ConstraintGraphNode and there's no need
to store the ConstraintSystem and TypeVariableType twice.
Also it doesn't need to be optional either, because we no longer need
to reset and recompute bindings.
All but two remaining call sites can be changed to just check for a
non-null solverState, because we want to assert if we're inside
of an active undo.
The two places inside binding inference can check isUndoActive()
directly.
Until `ApplicableFunction` constraint is simplified result type
associated with it cannot be bound because the binding set if
incomplete.
Resolves: rdar://139237088
Delaying such bindings is too restrictive and leads to subpar selections.
For `$T1` to be array or C-style pointer it would have to be
connected either to a type variable that could be bound to
array/pointer or directly to array/pointer type which would
result in the solver either selecting the other type variable
first (because it appears in adjacent variables of `$T1`) or
provide an additional binding(s) for `$T1` (including literals).
Consider the following constraint system:
```
$T2 arg conv $T1
$T2 conforms ExpressibleByIntegerLiteral
inout $T1 arg conv UnsafeMutablePointer<UInt8>?
```
If `$T1` and `$T2` are the only viable type variables delaying
`$T1` would mean that `$T2` is picked to attempt its default
type `Int` which is incorrect (it doesn't get `UInt8` because
there is no transitive inference through conversions).
Tuples in general do have conversions but an empty tuple or `Void`
doesn't, which means that if a type variable has a subtype binding
to `Void` it should be safe to prioritize.
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.
