Change the locator for the applicable fn
constraint for the inner subscript reference in an
implicit `outer[dynamicMember: \Inner.[0]]` expr
such that it uses the member locator with a
KeyPathDynamicMember element.
Then add a case to `getCalleeLocator` to handle
these locators. We also need to handle this
specially in `getArgumentInfoLocator` due to the
fact that the argument labels for the inner
subscript reference correspond to those written
by the user for the outer subscript reference.
Resolves SR-11933.
Resolves rdar://problem/57824025.
Previously we had a request for this in
IDETypeChecking, but this wasn't used for queries
made from Sema. Move the request into Sema, and
move `hasDynamicMemberLookupAttribute` onto
TypeBase.
If there was a mismatch between last component type and contextual
key path result type, let's try to re-match the types with all optionals
stripped off. In cases where the problem is optionality difference
e.g. `[Int] vs. [Int]?` that propagates contextual information to
the last component which facilitates better diagnostics.
Resolves: rdar://problem/57843297
If return of optional chaining is assigned to an optional type
or discarded there should be no force optional unwrap attempt
on it because type variable associated with context can be
bound to optional of any depth.
Resolves: rdar://problem/57668873
Rather than maintaining a linked list of overload
choices, which must be linearly searched each time
we need to lookup an overload at a given callee
locator, use a MapVector which can be rolled back
at the end of a scope.
Remove ResolvedOverloadSetListItem in favor of
using SelectedOverload, which avoids the need to
convert between them when moving from
ConstraintSystem to Solution.
It's possible to construct subscript member responsible for key path
dynamic member lookup in a way which is going to be self-recursive
and an attempt to lookup any non-existent member is going to trigger
infine recursion.
Let's guard against that by making sure that the base type of the
member lookup is different from root type of the key path.
Resolves: rdar://problem/50420029
Resolves: rdar://problem/57410798
Previously we were just searching for a resolved
overload with the same component index and anchor
for the key path. However unfortunately that found
dynamic member lookup overloads in certain cases,
leading to an incorrect mutability capability.
Change the logic such that it uses the callee
locator for a given key path component, ensuring
we only match against the "direct" callee, and
not any dynamic members it might be also referring
to.
Resolves SR-11896.
It might be either impossible to infer the base because there is
no contextual information e.g. `_ = .foo` or there is something
else wrong in the expression which disconnects member reference
from its context.
If it couldn't be determined precisely what is the structural
difference between two function types, let's still repair the
mismatch by ignoring contextual type.
Initially this problem was only detected and diagnosed for calls.
So let's extend it to function conversions as well e.g.:
```swift
func foo<T>(_: [T]) {}
func bar<T>(_ f: (T...) -> ()) {}
bar { foo($0) }
```
Add a case to getCalleeLocator to return the
appropriate locator for a call to an implicit
callAsFunction member reference.
Resolves SR-11386 & SR-11778.
Locator builders keep a pointer to their underlying
locator, so it's not generally sound to extend an
rvalue locator builder.
This commit enforces that withPathElement is called
on an lvalue, and adds a couple more overloads of
getConstraintLocator to make it more convenient to
extend locators with multiple elements.
Some constraint transformations require knowledge about what state
constraint system is currently in e.g. `constraint generation`,
`solving` or `diagnostics` to make a decision whether simplication
is possible. Notable example is `keypath dynamic member lookup`
which requires a presence of `applicable fn` constraint to retrieve
some contextual information.
Currently presence or absence of solver state is used to determine
whether constraint system is in `constraint generation` or `solving`
phase, but it's incorrect in case of `diagnoseFailureForExpr` which
tries to simplify leftover "active" constraints before it can attempt
type-check based diagnostics.
To make this more robust let's introduce (maybe temporarily until
type-check based diagnostics are completely obsoleted) a proper
notion of "phase" to constraint system so it is always clear what
transitions are allowed and what state constraint system is
currently in.
Resolves: rdar://problem/57201781
Instead of always attempting an optional unwrap fix if types differ
in optionality, let's make it more targeted for each applicable
locator and conversion.
In addition adjust a couple of uses of `ForceOptional` fix to avoid
recording the same fix multiple times and use appropriate `impact`
instead.
diagnosing failures in applySolutionFixes, coalesce fixes and
diagnose failures in one method on ConstraintFix.
This eliminates the need for the `DefaultGenericArgument` fix (which
was renamed from `ExplicitlySpecifyGenericArguments`) to have an
array of missing parameters, which was only used when the fixes were
coalesced. Instead, the coalesced arguments are used to create the
`MissingGenericArgumentsFailure` diagnostic directly.
Detect and diagnose a problem when explicitly specified closure
result type doesn't match what is expected by the context:
Example:
```swift
func foo(_: () -> Int) {}
foo { () -> String in "" } // `Int` vs. `String`
```
