If base type of a unresolved member reference couldn't be determined
(represented as a hole type), before recording a fix about lack of
contextual information, let's make sure that hole originated in either
base or result type of this reference, otherwise the problem is
contextual e.g. generic parameter, which supposed to act as contextual
type for a reference, couldn't be inferred.
If the right-hand side (destination) of value-to-pointer conversion
is incorrect e.g. base type of member is a hole, let's record
a generic "invalid conversion" failure.
Resolves: rdar://problem/68254165
In situations where left-hand side requires value-to-optional
promotion which ends up in type mismatch let's not mention
optionals in the diagnostic because they are unrelated e.g.
```swift
func test(_: UnsafePointer<Int>??) {}
var value: Float = 0
test(&value)
```
In this example `value` gets implicitly wrapped into a double optional
before `UnsafePointer<Float>` could be matched against `UnsafePointer<Int>`
associated with the parameter.
Diagnostic is about generic argument mismatch `Float` vs. `Int`
and shouldn't mention any optionals.
* [CSDiagnostics] Handle arg to param generic when locator points to ConstraintLocator::GenericArgument
* [test] Add SR-12242 test case
* [CSDiagnostics] Handle arg to param on Generic mismatch as a fallback diagnostic
* [CSDiagnostics] Make assign diagnostics in GenericMismatchFailure handle more cases
* [test] Adding test cases for assign expr in GenericMismatch diagnostics
* [CSDiagnostics] Improving inout to pointer argument conversions with optionals diagnostics
These include the pointer-to-pointer and pointer-to-buffer-pointer
initialiser parameters amongst a couple of others, such as
`Unmanaged.fromOpaque`, and the source for the `move[...]` family of
methods.
The existing verification seems unnecessarily brittle, but this isn't
a general fix for that problem. This fixes one instance of where we
are generating perfectly valid pointer conversions that the verifier
is currently blowing up on.
I've opened https://bugs.swift.org/browse/SR-8264 to track reworking
this verification to not be quite so brittle.
