This helps with:
- Diagnostics because solver would get more choices to work with
in diagnostic mode;
- Avoid adding the same overload multiple times
(retry after label mismatch and no viable candidates);
- Unify overload handling/filtering in `simplfyAppliedOverloads`.
Simplify the interface to gatherConstraints() by performing the
uniquing within the function itself and returning only the resulting
(uniqued) vector of constraints.
Diagnose situation when a single "tuple" parameter is given N arguments e.g.
```swift
func foo<T>(_ x: (T, Bool)) {}
foo(1, false) // foo exptects a single argument of tuple type `(1, false)`
```
Remove this additional note when attempting to incorrectly initialize UnsafePointer:
Pointer conversion restricted: use '.assumingMemoryBound(to:)' or
'.bindMemory(to:capacity:)' to view memory as a type.
The note was added for Swift 3 migration. The idea was to get projects
building as quickly as possible and effectively tag bad behavior so it
could be corrected later. That worked, but now it's been working
against us for the past couple of releases. Too much new code is using
these two APIs and the vast majority of uses are not only incorrect,
but much more simply expressed without them. Instead, programmers need
to be made aware that the UnsafeRawBufferPointer API already does what
they want... but we can work on that problem as separate task.
Most uses of these APIs are something like:
return rawptr.assumingMemoryBound(to: T.self).pointee
or
UnsafeRawPointer(ptr).bindMemory(to: UInt16.self, capacity: 2).pointee
Instead of simply
return rawptr.load(as: T.self)
I've even seen programmers do this:
extension UnsafeRawPointer {
var uint8: UInt8 {
let uint8Ptr = self.bindMemory( to: UInt8.self, capacity: 1 )
return uint8Ptr[0]
}
}
...instead of simply using either UnsafeRawPointer.load or UnsafeRawBufferPointer's subscript.
Since there is already a diagnostic for this `MemberAccessOnOptionalBaseFailure`
it should incorporate all related diagnostic logic and could be used from CSDiag.
Extend use of "instance member on type" fix to cover potentially
invalid partial applications, references to instance members on
metatypes, and remove related and now obsolete code from `CSDiag`.
Resolves: [SR-9415](https://bugs.swift.org/browse/SR-9415)
There's no way to spell an opaque type in a cast, and that means
there's no way to force the conversion today (even if you know the
types are dynamically the same).
Part of rdar://problem/50346954
Replace dedicated method with `typeCheckChildIndependently` always
setting the closest possible declaration context for type-check call.
This fixes a problem where sub-expression comes from multiple levels
or nested closures but CSDiag didn't re-typecheck parent closure.
Resolves: rdar://problem/50869732
It's only needed in one place in the constraint solver to allow
`() -> T` to `() -> ()` and `() -> Never` to `() -> T` for expressions
representing return of a single expression functions, so to simplify
contextual type handling in diagnostic and other places it would be
better to replace dedicated locator kind with a flag on existing `ContextualType`.
Resolves: rdar://problem/51641323
Use this function to replace various places where the logic is
duplicated.
In addition, isolate the logic where subscripts are treated as having
curried self parameters to CalleeCandidateInfo, as their interface types
don't have a curried self, but get curried with self by
CalleeCandidateInfo. Ideally we'd fix this by having a subscript's
interface type be curried with self, but given that most of this CSDiag
logic should be going away, this may not be necessary.
All places where `invalid member ref` fix/diagnostic is used already
have a reference to the potential member choice declaration, which
diagnostic could take advantage of.
This is useful for `CSDiag` when it detects that all
overload choices have the same problem. Since there
are going to be no solutions, choice declaration could
be supplied to `invalid ref` diagnostic directly.
Resolves: rdar://problem/50467583
Resolves: rdar://problem/50682022
Resolves: rdar://problem/50909555
Originally `filterContextualMemberList` would only return a limited
set of closeness kinds `CC_GeneralMismatch`, `CC_Argument{Label, Count}Mismatch`,
and unavailable/inaccessible. At some point later it also started
matching almost everything besides `CC_SelfMismatch` and logic in
`visitUnresolvedMemberExpr` needs to get adjusted to account for that.
Resolves: rdar://problem/50668864
Extend use of `missing protocol conformance` fix to cover contextual
failures, such as:
- Assignment mismatches, where destination requires source to conform
to certain protocol (or protocol composition);
- Incorrect returns where returned type doesn't conform to the
protocol specified in the signature.
