Instead of making an undo() do an infer(), let's record fine-grained
changes about what was retracted, and directly re-insert the same
elements into the data structures.
The two GatherKinds no longer share any implementation, so there's
no point keeping the logic together. Doing this also allows removing
the acceptConstraintFn from gatherAllConstraints(), which further
simplifies depthFirstSearch().
* [ConstraintSystem] Add index value (as an impact of the score kind) to debug constraints.
* Use weight instead of index, change label 'value' -> 'impact'
* Fix debug constraints output format: remove 'components' and add 'weight' label
If type equality check fails we need to check whether the types
are the same with deep equality restriction since `any Sendable`
to `Any` conversion is now supported in generic argument positions
of @preconcurrency declarations. i.e. referencing a member on
`[any Sendable]` if member declared in an extension that expects
`Element` to be equal to `Any`.
Put AvailabilityRange into its own header with very few dependencies so that it
can be included freely in other headers that need to use it as a complete type.
NFC.
Use `simplifyType` instead with the new parameter
for getting an interface type. Also avoid using
`resolveInterfaceType` in CSApply since we don't
need the opened generic parameter mapping behavior.
Rather than attempting to re-implement `simplifyType`,
tweak `Solution::simplifyType` such that it can
map the resulting type out of context, and can
turn type variables into their opened generic
parameters.
Instead of using `one-way` constraints, just like in closure contexts
for-in statements should type-check their `where` clauses separately.
This also unifies and simplifies for-in preamble handling in the
solver.
Instead of starting a depth-first search from each type variable
and marking all type variables that haven't been marked yet,
we can implement this as a union-find.
We can also store the temporary state directly inside the
TypeVariableType::Implementation, instead of creating large
DenseMaps whose keys range over all type variables.
Don't attempt this optimization if call has number literals.
This is intended to narrowly fix situations like:
```swift
func test<T: FloatingPoint>(_: T) { ... }
func test<T: Numeric>(_: T) { ... }
test(42)
```
The call should use `<T: Numeric>` overload even though the
`<T: FloatingPoint>` is a more specialized version because
selecting `<T: Numeric>` doesn't introduce non-default literal
types.
Helps situations like `1 + {Double, CGFloat}(...)` by inferring
a type for the second operand of `+` based on a type being constructed.
Currently limited to Double and CGFloat only since we need to
support implicit `Double<->CGFloat` conversion.
Helps situations like `1 + CGFloat(...)` by inferring a type for
the second operand of `+` based on a type being constructed.
Currently limited to known integer, floating-point and CGFloat types
since we know how they are structured.
