This is required because `ApplicableFunction` constraint can
inject member reference constraints that require a declaration
context.
For example, `_ = { Double(...) }` would now produce a disjunction
for `Double.init` where overload choice declaration contexts point
to the closure instead of the enclosing context.
This addresses a long-standing FIXME in `simplifyApplicableFnConstraint`
and helps with disjunction optimizer because its correctness depends on
correct identification of declaration contexts where applications happen.
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().
Recently I found a soundness hole here, where we would allow conversion
between `any P<T>` and `any Q<T>` even if P and Q have different primary
associated types.
However, the fix was too strict, because we still want to allow the
conversion when the associated types have the same name.
Fixes rdar://141968103.
Allow `InsertExplicitCall` for e.g converting
`() -> () -> Void` to `() -> Void`. No test since
it's already covered in the test suite when the
next commit is applied.
Re-introduce unsolved member constraint when optional object is
a type variable or member until it's bound, otherwise it's impossible
to tell whether unwrapped base would have a member or not.
If result of `CGFloat` -> `Double` conversion is injected into an optional
it should be ranked based on depth just like when locator is fully simplified.
For example:
```swift
func test(v: CGFloat?) {
_ = v ?? 2.0 / 3.0
}
```
In this expression division should be performed on `Double` and result
narrowed down (based on the rule that narrowing conversion should always
be delayed) but `Double` -> `CGFloat?` was given an incorrect score and
instead of picking `?? (_: T?, _: T) -> T` overload, the solver would
use `?? (_: T?, _: T?) -> T?`.
Allow `any Sendable` to match `Any` constraint while matching
generic arguments i.e. `[any Sendable]` -> `[Any]` when `any Sendable`
type comes from context that involves `@preconcurrency` declarations
in non-strict concurrency compiler mode.
Note that it's currently impossible to figure out precisely
where `any Sendable` type came from.
Prevent generic arguments from being assigned `any Sendable`
directly, that should only happen through inference. This is
required because we allow `any Sendable` -> `Any` conversion
in modes without strict concurrency enabled to maintain source
compatibility and let the developers annotate existing APIs
with `any Sendable` and other concurrency attributes.
If a (trailing) closure is determined to be an extraneous argument
for one of the overload choices it needs to be marked as hole as
eagerly as possible and prevented from being resolved because
otherwise it's going to be disconnected from the rest of the
constraint system and resolution might not be able to find all of
the referenced variables. This could result either in crashes
or superfluous diagnostics.
Resolves: rdar://141012049
Avoid wrapping parameters in the function reference
for compound applies, and make sure we consult
the parameter label in the compound name if it's
present to determine whether to match using the
projected value or not. This matches the existing
logic in `unwrapPropertyWrapperParameterTypes`.
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.
