`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
Type inside of an editor placeholder is more of a hint than anything else,
so if it's incorrect let's diagnose that and use type variable instead to
allow solver to make forward progress.
Resolves: SR-14213
Resolves: rdar://74356736
A lot of operators (and most likely regular functions a well) have
overloads that accept i.e. a generic parameter that conforms to
`StringProtocol`, so the best fix in situations when argument is
a raw representable type would be to check whether `.rawValue`
conforms to the expected protocol and use it if so.
Resolves rdar://problem/75367157
Since labels are considered part of the name, mismatches in labeling
should be invalidate overload choices. Let's prefer an overload with
correct labels but incorrect types over the one with incorrect labels.
This also means that it's possible to restore performance optimizations
related to early filtering in diagnostic mode, which is important for
deeply nested code i.e. SwiftUI views.
Is the same argument is out-of-order in multiple solutions, let's
diagnose it as if there was no ambiguity.
Resolves: SR-14093
Resolves: rdar://73600328
It's possible that different overload choices could have the same
conformance requirement, so diagnostics should be able to emit an
error in situations where multiple solutions point to the missing
conformance at the same location (both in AST and requirement list).
Resolves: rdar://74447308
If one of the statements in the result builder body fails to
apply solution, let's fail entire rewrite attempt, otherwise
type-checker would end up with AST that has null pointers for
some child nodes.
Resolves: rdar://problem/70256351
Can't use `ConstraintSystem::addImplicitLoadExpr` because that would
only cache types in constraint system and wouldn't propagate them to AST,
since that happens in `ExprRewritter::finalize` during regular solution
application. `TypeChecker::addImplicitLoadExpr` should be used directly
in cases like that.
Resolves: rdar://problem/58972627
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
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
