`TrailingClosureAmbiguityFailure::diagnoseAsNote()` is used by
`diagnoseAmbiguity` opportunistically, which means that anchor
could be a pattern or a statement condition element.
Fixes a crash during diagnostics by not assuming that optional chain
would always produce an optional type, which is not true because in
error scenarios it could get assigned an invalid type from context.
Resolves: rdar://85516390
Contextual type could be a type variable or a type with type variables
that have a set of generic requirements, so affected declaration is
the owner of the generic parameter.
- Allow `SpecifyClosureReturnType` to be diagnosed in ambiguous context
- Add a tailoed diagnostic for when it's impossible to infer a type of
an empty closure
Resolves: rdar://88256059
Replace the existing `-enable-experimental-clang-importer-diagnostics`
flag with an opt-out version entitled `-disable-experimentalc-clang-importer-diagnostics`.
Enable the beviour previously hidden behind the old flag by default.
Clang importer diagnostics that are produced as a result of a reference
in Swift code are attached to as notes to the Sema produced diagnostic
that indicates the declaration is unavailable.
Ex: Notes about why a C function import failed are attached to
the error explaining that the symbol could not be found in scope.
Insert an implicit conversion from pack types to tuples with equivalent parallel structure. That means
1) The tuple must have the same arity
2) The tuple may not have any argument labels
3) The tuple may not have any variadic or inout components
4) The tuple must have the same element types as the pack
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.
}
```
