This commit essentially consistes of the following steps:
- Add a new code completion key path component that represents the code completion token inside a key path. Previously, the key path would have an invalid component at the end if it contained a code completion token.
- When type checking the key path, model the code completion token’s result type by a new type variable that is unrelated to the previous components (because the code completion token might resolve to anything).
- Since the code completion token is now properly modelled in the constraint system, we can use the solver based code completion implementation and inspect any solution determined by the constraint solver. The base type for code completion is now the result type of the key path component that preceeds the code completion component.
This resolves bugs where code completion was not working correctly if the key path’s type had a generic base or result type. It’s also nice to have moved another completion type over to the solver-based implementation.
Resolves rdar://78779234 [SR-14685] and rdar://78779335 [SR-14703]
Let's look through all optionals associated with contextual
type to make it possible to infer parameter/result type of
the closure faster e.g.:
```swift
func test(_: ((Int) -> Void)?) {
...
}
test { $0 + ... }
```
In this case dropping optionality from contextual type
`((Int) -> Void)?` allows `resolveClosure` to infer type
of `$0` directly (via `getContextualParamAt`) instead of
having to use type variable inference mechanism.
type to the locator.
This will provide context for tuple element mismatch diagnostics, instead
of attempting to compute the full tuple type in diagnostics code with a pile
of special cases (see getStructuralTypeContext in CSFix.cpp).
Use `findSelectedOverloadFor` instead of `findResolvedMemberRef`
to cover cases where member is found via base type unwrap, otherwise
conformance constraint would be re-inserted but never re-attempted
which results in a compiler crash.
Resolves: rdar://79268378
While checking whether compiler needs to produce a checked cast warning,
account for the fact that "from" could be less optional than "to" e.g.
`0 as Any?`, so the difference has to be stored as a signed integer
otherwise it's going to underflow and result in a crash or infinite
recursion in the diagnostics.
Resolves: rdar://79523605
With isolated parameters being part of a function's type, check to
ensure that isolated and non-isolated parameters aren't incorrectly
matched. Specifically, it is okay to add `isolated` to a parameter
when there is a subtyping relationship, but not remove it:
```swift
actor A { }
func f(_: isolated A) { }
func g(_: A) { }
func test() {
let _: (isolated A) -> Void = g // okay to add 'isolated'
let _: (A) -> Void = f // error when removing 'isolated'
}
```
Without context synthesized argument would be inferred as a hole,
so let's not record any additional fixes for it if there is no way
to infer it properly from a parameter (which could also be a hole
if it is a generic parameter type).
Resolves: rdar://78781552
If relational constraint has the same dependent member type on both
sides e.g. `$T1.Element == $T1.Element` allow its simplification,
since inference of `$T1` results in dependent member being resolved
to the same concrete type. Otherwise constraint system would be left
with this constraint in inactive state if `$T1` couldn't be resolved
which results in a crash.
Resolves: rdar://78623338
For `async` function types, an actor constraint can be enforced by the callee by hopping executors,
unlike with `sync` functions, so doesn't need to influence the outward type of the function.
rdar://76248452
This helps in situations where there are multiple overloads which
differ only in async effect of their parameters. Passing sync argument
to a sync parameter is always preferred and when detected early
allows solver to avoid some of the duplicate work re-solving for
the rest of the path e.g.
```swift
func test<T>(_: () -> T) {}
func test<T>(_: () async -> T) {}
test {
// sync work
}.op(...)
```
In this case since closure is synchronous first overload of `test`
is always preferred (when it's a match) and solver can skip re-checking
body of the closure and `op` call when it encounters `async` version.
Resolves: rdar://77942193
In overloaded context it's possible that there is an overload that
expects a closure but it can have other issues e.g. different number
of parameters, so in order to pick a better solution let's always
increase a score for overloads where closure is matched against a
non-function type parameter.
When `nil` is passed as an argument to call with multiple overloads
it's possible that this would result in ambiguity where matched
expected argument type doesn't conform to `ExpressibleByNilLiteral`.
To handle situations like this locator for contextual mismatch
has to be adjusted to point to the call where `nil` is used, so
`diagnoseAmbiguityWithFixes` can identify multiple overloads and
produce a correct ambiguity diagnostic.
Resolves: rdar://75514153
Let's make use of a newly added "disable for performance" flag to
allow solver to consider overload choices where the only issue is
missing one or more labels - this makes it for a much better
diagnostic experience without any performance impact for valid code.
`ContextualFailure` is the main beneficiary of additional information
associated with `ContextualType` element because it no longer has to
query solution for "purpose" of the contextual information.
Resolves: rdar://68795727
Having purpose attached to the contextual type element makes it much
easier to diagnose contextual mismatches without involving constraint
system state.
This saves us from needing to re-match args to params in CSApply and is also
useful for a forthcoming change migrating code completion in argument position
to use the solver-based typeCheckForCodeCompletion api.
rdar://76581093
Restrict filtering in `simplifyAppliedOverloadsImpl` to disable
overload set for operators only, because other calls e.g. regular
functions or subscripts could be filtered on labels and are less
overloaded.
Filtering non-operator calls could also lead to incorrect diagnostics
because first choice could have all sorts of different issues e.g.
incorrect labels and number of parameters.
Resolves: rdar://55369704
If left-hand side of a conversion that requires l-value is a placeholder type,
let's fix that by propagating placeholder to the order side (to allow it to
infer a placeholder if needed) without recording a fix since placeholder can
be converted to `inout` and/or l-value and already indicates existence of a
problem at some other spot in the expression.
Resolves: rdar://76250381
It's not always clear what generic parameter type implicit conversion to pointer
is going to have, and its safer to check direct conformance in `simplifyTransitivelyConformsTo`
and let parameter handle the rest.
Performance optimization to help rule out generic overload choices sooner.
This is based on an observation of the constraint solver behavior,
consider following example:
```swift
func test<U: ExpressibleByStringLiteral>(_: U) {}
test(42)
```
Constraint System for call to `test` is going to look like this:
```
$T_test := ($T_U) -> $T_U
$T_U <conforms to> ExpressibleByStringLiteral
$T_42 <argument conversion> $T_U
$T_42 <literal conforms to> ExpressibleByIntegerLiteral
```
Currently to find out that `test` doesn't match, solver would have
to first find a binding for `$T_42`, then find a binding for `$T_U`
(through `<argument conversion>` constraint) and only later fail
while checking conformance of `Int` to `ExpressibleByStringLiteral`.
Instead of waiting for parameter to be bound, let's transfer conformance
requirements through a conversion constraint directly to an argument type,
since it has to conform to the same set of protocols as parameter to
be convertible (restrictions apply i.e. protocol composition types).
With that change it's possible to verify conformances early and reject
`test<U: ExpressibleByStringLiteral>` overload as soon as type of an
argument has been determined. This especially powerful for chained calls
because solver would only have to check as deep as first invald argument
binding.
Conformance constraints could be transferred through conversions,
but that would also require checking implicit conversions
such as optional and pointer promotions for conformance is the
type itself doesn't conform, for that let's add a special constraint
`TransitivelyConformsTo`.
I couldn't come up with an isolated test-case to add to the suite,
but it's possible that `getProtocol` returns `nullptr` for invalid
or missing protocol so there has to be a check for that otherwise
compiler is going to crash trying to access `getDeclaredType()`.
Resolves: rdar://76187450
Performance optimization.
If there is a concrete contextual type we could use, let's bind
it to the external type right away because internal type has to
be equal to that type anyway (through `BindParam` on external type
i.e. <internal> bind param <external> conv <concrete contextual>).
```swift
func test(_: ([String]) -> Void) {}
test { $0 == ["a", "b"] }
```
Without this optimization for almost all overloads of `==`
expect for one on `Equatable` and one on `Array` solver would
have to repeatedly try the same `[String]` type for `$0` and
fail, which does nothing expect hurts performance.
Resolves: rdar://19836070
Resolves: rdar://19357292
Resolves: rdar://75476311
