Missed this in my original patch, handle pack parameters the same as
regular generic parameters, ensuring we don't prefer a pack overload
over a generic overload just because there are pointer conversions
involved. Note this doesn't fix the wider issue of rdar://122011759,
I'm planning on looking into that in a follow-up.
We ought to consider outright banning these conversions if the
destination is a generic parameter type, but for now let's penalize
them such that we don't end up with ambiguities if you're doing an
implicit pointer conversion through an identity generic function.
rdar://161205293
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
Delaying such bindings is too restrictive and leads to subpar selections.
For `$T1` to be array or C-style pointer it would have to be
connected either to a type variable that could be bound to
array/pointer or directly to array/pointer type which would
result in the solver either selecting the other type variable
first (because it appears in adjacent variables of `$T1`) or
provide an additional binding(s) for `$T1` (including literals).
Consider the following constraint system:
```
$T2 arg conv $T1
$T2 conforms ExpressibleByIntegerLiteral
inout $T1 arg conv UnsafeMutablePointer<UInt8>?
```
If `$T1` and `$T2` are the only viable type variables delaying
`$T1` would mean that `$T2` is picked to attempt its default
type `Int` which is incorrect (it doesn't get `UInt8` because
there is no transitive inference through conversions).
Allow inferring type of `inout` from a pointer type
(or optional thereof) but delay the binding set because
it might not be complete and object type of `inout` could
also be an Array or C-style pointer type.
- Don't attempt to insert fixes if there are restrictions present, they'd inform the failures.
Inserting fixes too early doesn't help the solver because restriction matching logic would
record the same fixes.
- Adjust impact of the fixes.
Optional conversions shouldn't impact the score in any way because
they are not the source of the issue.
- Look through one level of optional when failure is related to optional injection.
The diagnostic is going to be about underlying type, so there is no reason to print
optional on right-hand side.
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.
