Diagnostics cannot assume that solution would always be applied
to the constraint system, so all of the elements affected by the
mismatch have to be determined by the fix.
Resolves: rdar://85021348
Implicit conversion between optional types are not currently supported,
this includes optional chaining:
```
struct S {
var test: CGFloat
}
func compute(s: Double?) -> Double? {
return 42
}
func test(s: S?) {
_ = compute(s?.test) // CGFloat? -> Double? implicit conversion
}
```
Since `S` is optional, `test` ends up optional as well and that
wasn't correctly detected, so solver was allowed to form a correct
solution because `CGFloat` is converted to `Double` inside of
the chain _prior_ to it being wrapped into an optional because
contextual type of `Double` is propagated to the result of the
chain earlier that conversion takes place.
Resolves: rdar://83666783
In situations like `_ = ... as! Bool!` the `to` type could either
be represented by an optional (default) or unwrapped. Coercion warnings
cannot assume that `to` (even though its IUO) is always represented
as an optional type.
Resolves: rdar://83072606
A contextual purpose for a sequence expression associated with
`for-in` statement, that decays into a `ConformsTo` constraint
to a `Sequence` or `AsyncSequence` protocol.
Note that CTP_ForEachSequence is almost identical to CTP_ForEachStmt
but the meaning of latter is overloaded, so to avoid breaking solution
targets I have decided to add a new purpose for now.
Diagnose situations where Swift -> C pointer implicit conversion
is attempted on a Swift function instead of one imported from C header.
```swift
func test(_: UnsafePointer<UInt8>) {}
func pass_ptr(ptr: UnsafeRawPointer) {
test(ptr) // Only okay if `test` was an imported C function.
}
```
Diagnose situations where `weak` attribute is used with a non-optional type
in declaration e.g. `weak var x: <Type>`:
```swift
class X {
}
weak var x: X = ...
```
`weak` declaration is required to use an optional type e.g. `X?`.
from missing function call errors in `ContextualFailure`.
It doesn't make sense to diagnose pattern matching errors inside of
`diagnoseMissingFunctionCall`, and the code I added to bail out if there
is no explicit function expression broke the pattern matching diagnostics
anyway.
- Explicitly limit favoring logic to only handle
unary args, this seems to have always been the
case, but needs to be handled explicitly now that
argument lists aren't exprs
- Update the ConstraintLocator simplification to
handle argument lists
- Store a mapping of locators to argument lists
in the constraint system
- Abstract more logic into a getArgumentLocator
method which retrieves an argument-to-param locator
from an argument anchor expr
Just for convenicence.
* Replace `llvm::isa_and_nonnull` with imported `isa_and_nonnull`
* Repalce some `EXPR && isa<T>(EXPR)` with `isa_and_nonnull<T>(EXPR)`
