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.
Solutions passed to `diagnoseAmbiguityWithFixes` aren't filtered
so we need to remove all of the solutions with the score worse
than overall "best". Also logic has to account for some fixes being
"warnings".
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) }
```
If none of the candidates produce expected contextual type, record
all of the posibilities to produce a note per and diagnose this as
contextual type mismatch instead of a reference ambiguity.
We still want the constraint system to try looking up
a callAsFunction method even if it's inaccessible, as
we'll be able to record a fix and emit a suitable
diagnostic.
Rather than coercing the call arguments ourselves,
just build the finished member reference for the
callAsFunction method, and let finishApply do the
rest. This allows us to deal with transformations
such as IUO unwraps.
Resolves SR-11881.
Add a case to getCalleeLocator to return the
appropriate locator for a call to an implicit
callAsFunction member reference.
Resolves SR-11386 & SR-11778.
Move `buildDynamicMemberLookupIndexExpr` into
ExprRewriter, and pass the string literal through
`handleStringLiteralExpr` to properly handle its
coercion to the parameter type.
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.
When an overriding property containing willSet or didSet is not within
a type, the type checker could crash due to a missing "self"
declaration. Check this condition. Fixes rdar://problem/57040259.
Note: The change in ASTBuilder::createFunctionType is functionally minor,
but we need the FunctionType::Params computed _before_ the ExtInfo, so we
need to shuffle a bunch of code around.
