If one of the sides in a application result conversion is a hole
it could only mean that the fix has been recorded earlier (at the
point where hole was introduced) and failure at function result
position could be safely ignored.
Resolves: rdar://79757320
If lookup failed to find a member for a pattern match, let's bind
type variable representing such member to a hole right away, otherwise
there is a risk of missing other potential hole locations in pattern
function type (arguments + result type) because pattern matching
doesn't use 'applicable function' constraint.
Resolves: rdar://65667992
Treat actors as being semantically `final` throughout the type checker.
This allows, for example, a non-`required` initializer to satisfy a
protocol requirement.
We're leaving the ABI open for actor inheritance should we need it.
Addresses rdar://78269551.
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
