Assert that we have a correct locator and that we
recorded argument information for it, rather than
returning no information.
In addition, always return the callee locator,
even if there is no callee.
Introduce a new kind of constraint, the "value witness" constraint,
which captures a reference to a witness for a specific protocol
conformance. It otherwise acts like a more restricted form of a "value
member" constraint, where the specific member is known (as a
ValueDecl*) in advance.
The constraint is effectively dependent on the protocol
conformance itself; if that conformance fails, mark the type variables
in the resolved member type as "holes", so that the conformance
failure does not cascade.
Note that the resolved overload for this constraint always refers to
the requirement, rather than the witness, so we will end up recording
witness-method references in the AST rather than concrete references,
and leave it up to the optimizers to perform devirtualization. This is
demonstrated by the SIL changes needed in tests, and is part of the
wider resilience issue with conformances described by
rdar://problem/22708391.
Introduce a `ImplicitCallAsFunction` locator path
element to represent an implicit member reference
to `callAsFunction`. Then adjust CSApply a little
to check whether it's finishing an apply for a
callable type, and if so build the implicit member
access.
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.
