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.
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.
Detect difference in escapiness while matching function types
in the solver and record a fix that suggests to add @escaping
attribute where appropriate.
Also emit a tailored diagnostic when non-escaping parameter
type is used as a type of a generic parameter.
Enhance call-argument matching to reject trailing closures that match up
with parameters that cannot accept closures at all.
Fixes rdar://problem/50362170.
When type-checking a return statement's result, pass a new
ContextualTypePurpose when that return statement appears in a function
with a single expression. When solving the corresponding constraint
system, the conversion constraint will have a new ConstraintKind. When
matching types, check whether the constraint kind is this new kind,
meaning that the constraint is between a function's single expression
and the function's result. If it is, allow a conversion from
an uninhabited type (the expression's type) to anything (the function's
result type) by adding an uninhabited upcast restriction to the vector
of conversions. Finally, at coercion time, upon encountering this
restriction, call coerceUninhabited, replacing the original expression
with an UninhabitedUpcastExpr. Finally, at SILGen time, treat this
UninhabitedUpcastExpr as a ForcedCheckedCastExpr.
Eliminates the bare ConstraintSystem usage from
typeCheckFunctionBodyUntil, ensuring that the same code path is followed
for all function bodies.
We have a systemic class of issues where noescape types end up bound to
type variables in places that should not. The existing diagnostic for
this is ad-hoc and duplicated in several places but it doesn't actually
address the root cause of the problem.
For now, I've changed all call sites of createTypeVariable() to set the
new flag. I plan on removing enough occurrences of the flag to replicate
the old diagnostics. Then we can continue to refine this over time.
