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.
This is already accounted for by `determineBestChoicesInContext`
and reflected in the overall score, which means that we no longer
need to use this in vacuum.
Just because the type of the initializer expression is an opaque return type,
does not mean it is the opaque return type *for the variable being initialized*.
It looks like there is a bit of duplicated logic and layering violations going
on so I only fixed one caller of openOpaqueType(). This addresses the test case
in the issue. For the remaining calls I added FIXMEs to investigate what is
going on.
Fixes https://github.com/swiftlang/swift/issues/73245.
Fixes rdar://127180656.
FunctionRefKind was originally designed to represent
the handling needed for argument labels on function
references, in which the unapplied and compound cases
are effectively the same. However it has since been
adopted in a bunch of other places where the
spelling of the function reference is entirely
orthogonal to the application level.
Split out the application level from the
"is compound" bit. Should be NFC. I've left some
FIXMEs for non-NFC changes that I'll address in a
follow-up.
