This commit replaces the `getValue()` and `getValue2()` members on
`ConstraintLocator::PathElement` with specific accessors for each
expected path component kind. IMO this adds some clarity to the call
sites, especially for `getArgIdx()` and `getParamIdx()`.
In addition, this commit adds a private `getValue` member that can
access a value at a given index, which will make it easier to add a
third value in the future.
Functions like `isRawRepresentable*` and `conformsToKnownProtocol`
have to be be shared between CSDiag and new diagnostics framework
until relevant code is removed from the former.
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
