Rather than re-walk the pattern to create type bindings for the variables
that show up in the pattern, assign types to each of the variables as part
of constraint generation for the pattern. Only do this in contexts
where we will need the types, e.g., function builders.
Consider following example:
```swift
struct MyType<TyA, TyB> {
var a : TyA, b : TyB
}
typealias B<T1> = MyType<T1, T1>
_ = B(a: "foo", b: 42)
```
Here `T1` is equal to `TyA` and `TyB` so diagnostic about
conflicting arguments ('String' vs. 'Int') should only be
produced for "representative" `T1`.
Currently constraint solver is only capable of detecting universally unavailable
overloads but that's insufficient because it's still possible to pick a contextually
unavailable overload choice which could be better than e.g. generic overload, or
one with defaulted arguments, marked as disfavored etc.
Let's introduce `ConstraintSystem::isDeclUnavailable` which supports both universal
and contextual unavailability and allow constraint solver to rank all unavailable
overload choices lower than any other possible choice(s).
Resolves: rdar://problem/59056638
Don't attempt to figure out what exactly is ambiguous, let
`diagnoseAmbiguity` take care of that. Simplify make sure
that only some of the solutions have fixes and these fixes
are all related to use of ephemeral pointers.
Diagnose ambiguity related to overloaded declarations where only
*some* of the overload choices have ephemeral pointer warnings/errors
associated with them. Such situations have be handled specifically
because ephemeral fixes do not affect the score.
If all of the overloads have ephemeral fixes associated with them
it's much easier to diagnose through notes associated with each fix.
There were changes due to the StringRef to std::string conversion, changes
in the Debug Info DIBuilder::createModule API, and a drop in the using for
PointerUnion4 since PointerUnion is now a variadic template and will do in its
place.
It's done by first retrieving all generic parameters from each solution,
filtering boundings into distrinct set and diagnosing any differences.
For example:
```swift
func foo<T>(_: T, _: T) {}
func bar(x: Int, y: Float) {
foo(x, y)
}
```
Capture the peculiarities of contextual types vs. types used to generate
conversion constraints, as well as the behavior of “optional some” patterns
as used by if let / while let, within SolutionApplicationTarget. This allows
us to use a single target throughout setup / solving / application, rather
than mapping between two similar-but-disjoint targets.
Initializer expressions are always type checked against a pattern, so also
include the pattern in the solution application target and use that to
compute the contextual type from the pattern type.
Rework most of typeCheckExpression() to use SolutionApplicationTarget,
folding more information into that data structure and sinking more
expression-checking behavior down into the more general solver and
solution-application code.
When requesting information about the contextual type of a constraint
system, do so using a given expression rather than treating it like
the global state that it is.
The right solution is to extend the notion of the "anchor" of a locator
to also cover statements (and TypeReprs, and Patterns, and more), so
this is a stop-gap.
Fix `getArgumentExpr` to not assume that constraint system
always asks for index that exists in an argument tuple,
because sometimes arguments could be synthesized (such
arguments do not have corresponding expression).
Resolves: rdar://problem/56221372
`getCalleeLocator` has to be able to:
- Retrieve type for given expression via `getType`;
- Simplify given type via `simplifyType`; and
- Retrieve a selected overload choice for a given locator via `getOverloadFor`.
This is necessary for ambiguity diagnostics because none of the
solutions are applied back to the constraint system which means
that `getCalleeLocator` needs an ability to query information
from different sources e.g. constraint system and/or solution.
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.
