When in "existing" Swift code that is Swift 5.x and has not adopted
concurrency, allow mismatches in function types that only involve
ABI-neutral concurrency changes (e.g., adding `@Sendable` or removing
a global actor) by downgrading the diagnostic to a warning. This
improves the story for incremental adoption of concurrency in an
existing code base.
As part of this, generalize the facility for downgrading an error to a
warning when performing diagnostics in the constraint solver, using the
new diagnostic behavior limits rather than duplicating diagnostics.
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)`
