Introduce `repairByUsingRawValueOfRawRepresentableType` which is used for
assignment, argument-to-parameter conversions and contextual mismatches.
It checks whether `from` side is a raw representable type and tries
to match `to` side to its `rawValue`.
Also extract logic common for `repairByUsingRawValueOfRawRepresentableType`
and `repairByExplicitRawRepresentativeUse` into `isValueOfRawRepresentable`.
If either `MarkExplicitlyEscaping` or `TreatRValueAsLValue` fix
points to an argument-to-parameter conversion, let's add more
more clarifying argument to the locator to pinpoint the problem.
Detect situation when it's impossible to determine types for
closure parameters used in the body from the context. E.g.
when a call closure is associated with refers to a missing
member.
```swift
struct S {
}
S.foo { a, b in } // `S` doesn't have static member `foo`
let _ = { v in } // not enough context to infer type of `v`
_ = .foo { v in } // base type for `.foo` couldn't be determined
```
Resolves: [SR-12815](https://bugs.swift.org/browse/SR-12815)
Resolves: rdar://problem/63230293
When simplifying a keypath constraint with a function type binding, single-parameter functions have the parameter type and the return type matched against the keypath root and value; whereas multiple-parameter functions cause an ambiguous failure (in `simplifyKeyPathConstraint`).
Resolves rdar://problem/57930643
Previously we could allow some invalid coercions to
sneak past Sema. In most cases these would either
cause crashes later down the pipeline or
miscompiles. However, for coercions between
collections, we emitted somewhat reasonable code
that performed a force cast.
This commit aims to preserve compatibility with
those collection coercions that previously
compiled, and emits a warning telling the user to
use either 'as?' or 'as!' instead.
This helps to avoid allocating new type variables (which shouldn't be done regardless)
to store parameter indices when `missing arguments` diagnostic is used by other diagnostics.
Instead of always applying solution back to constraint system
before diagnostics, let's pass solution directly to `ConstaintFix::diagnose`
method to be used by `FailureDiagnostic` which paves a way for
stateless diagnostics.
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)
}
```
When it comes to contextual mismatches `ContextualType` is not guaranteed
to be the last element in the patch since contextual type could be a function
too which could would have `contextual type -> function argument` path.
Diagnose an attempt to reference a top-level name shadowed by
a local member e.g.
```swift
extension Sequence {
func test() -> Int {
return max(1, 2)
}
}
```
Here `min` refers to a global function `min<T>(_: T, _: T)` in `Swift`
module and can only be accessed by adding `Swift.` to it, because `Sequence`
has a member named `min` which accepts a single argument.
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.
