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)`
I missed this case when previously improving the
logic here. As it turns out, using the raw anchor
as the root expression from which to derive parent
information is insufficient. This is because it
may not capture relevant parent exprs not a part
of the fix locator.
Instead, pass down a function that can be used to
derive the parent expressions from the constraint
system's own parent map. Also make sure to assign
to `expr` for the UnresolvedMemberChainResultExpr
case to make sure we correctly check for it as a
sub-expression.
Finally, now that we're looking at more parent
exprs, add logic to handle `try` and `await`
parents, as well as ClosureExprs and
CollectionExprs. I couldn't come up with a test
case for CollectionExpr, as we emit different
diagnostics in that case, but it's probably better
to tend on the side of being more future proof
there.
rdar://81512079
* [TypeResolver][TypeChecker] Add support for structural opaque result types
* [TypeResolver][TypeChecker] Clean up changes that add structural opaque result types
Emit the specialized extraneous trailing closure
diagnostic for multiple trailing closures and
unlabelled unary argument lists, and add a
specialized trailing closure version for the multiple
extraneous case.
