Allow async calls and await expressions within @asyncHandler functions.
If we see an async call or await expression in a function that is not
an async context, also suggest adding @asyncHandler if the function
meets the semantic constraints.
Replace the uglified '__await' keyword with a contextual keyword
'await'. This is more of what we would actually want for the
concurrency model.
When concurrency is enabled, this will be a source-breaking change,
because this is valid Swift code today:
```swift
struct MyFuture<T> {
func await() -> }
func doSomething() {
let result = await()
}
}
```
but the call to `await()` will be parsed as an await expression when
concurrency is enabled. The source break is behind the experimental
concurrency flag, but this way we can see how much of an issue it is
in practice.
Closurea can become 'async' in one of two ways:
* They can be explicitly marked 'async' prior to the 'in'
* They can be inferred as 'async' if they include 'await' in the body
Implement missing restrictions on calls to 'async':
* Diagnose async calls/uses of await in illegal contexts (such as
default arguments)
* Diagnose async calls/uses of await in functions/closures that are not
asynchronous themselves
* Handle autoclosure arguments as their own separate contexts (so
'await' has to go on the argument), which differs from error handling
(where the 'try' can go outside) because we want to be more particular
about marking the specific suspension points.
Similar to `try`, await expressions have no specific semantics of their
own except to indicate that the subexpression contains calls to `async`
functions, which are suspension points. In this design, there can be
multiple such calls within the subexpression of a given `await`.
Note that we currently use the keyword `__await` because `await` in
this position introduces grammatical ambiguities. We'll wait until
later to sort out the specific grammar we want and evaluate
source-compatibility tradeoffs. It's possible that this kind of prefix
operator isn't what we want anyway.
* [CSDiagnostics] Adjusting MemberAccessOnOptionalBaseFailure to be able to handle key path component member base types
* [tests] Adding regression tests for SR-5688
* [CSDiagnostics] Adjusting source range to diagnose/insert the fixes in correct location
* [tests] Adjusting regression tests to handle the fixits
* [AST] Creating an helper getSourceRange function for KeyPathExpr::Component
* [ConstraintSystem] Store member base type when recording UnwrapOptionalBase fix
* [AST] Creating a new diagnostic note for removing optional from written type
* [CSDiagnostics] Adjusting logic around MemberAccessOnOptionalBaseFailure to emit the correct diagnostics and fixes
* [tests] Adjusting regression tests to add subscript and key path root cases with respective diagnostics
* [Diagnostics] Adjusting message to mention base type
* [CSDiagnostics] Better naming for method/variable that represents base source range
* [CSDiagnostics] Adjusting to use the stored base member only when member is a key path component.
* [Diagnostics] Adjusting minor typos and code
* [AST] Adjusting keypath root diagnostic note message for use unwrapped type
* [CSDiagnostics] Adjusments in MemberAccessOnOptionalBaseFailure diagnostics as per suggestion
* [tests] Adding more test cases for SR-5688
* [CSDiagnostics] Adjusting fixits for key path root and range for diagnostics
* [CSSimplify] Attempt to diagnose InsertExplicitCall for optional function return types when possible on simplifyOptionalObjectConstraint
* [tests] Adding TODO to improve the diagnostics refering to key path root infered as optional types
* [CSDiagnostics] Adjusting comments
* [CSSimplify] Adjusting logic on simplifyOptionalObjectConstraint to attempt InsertCall fix before remove unwrap
* [CSDiagnostics] Adjust the logic to use resolveType on MemberAccessOnOptionalBaseFailure construction
Currently it's possible to have a type conflict between different
requirements deduced as the same type which leads to incorrect
diagnostics. To mitigate that let's adjust how "fixed" requirements
are stored - instead of using resolved type for the left-hand side,
let's use originating generic parameter type.
Instead of requiring sub-classes of `ContextualMismatch` to implement
`diagnoseForAmbiguity` let's implement it directly on `ContextualMismatch`
itself and check whether all of the aggregated fixes have same types on
both sides and if so, diagnose as-if it was a single fix.
We currently leave a key path constraint unsolved
if one of its components hasn't yet had its
overload resolved. However, for e.g a missing
member component, the overload type variable will
be bound to a hole and an overload will never be
resolved.
Tweak the logic to consider the key path constraint
trivially solved if one of its components has been
marked as a hole, which will allow the key path
type itself to be marked as a hole.
Resolves SR-12437 & SR-12823.
Resolves rdar://62201037.
Detect situation when it's impossible to determine types for
closure parameters used in the body from the context. E.g.
when a call closure is associated with refers to a missing
member.
```swift
struct S {
}
S.foo { a, b in } // `S` doesn't have static member `foo`
let _ = { v in } // not enough context to infer type of `v`
_ = .foo { v in } // base type for `.foo` couldn't be determined
```
Resolves: [SR-12815](https://bugs.swift.org/browse/SR-12815)
Resolves: rdar://problem/63230293
If a Swift key path has root type inferred but does not have a leading dot,
then diagnose it, because it's not valid.
For example:
```swift
struct Foo {
let property: [Int] = []
let kp: KeyPath<Foo, Int> = \property.count // error
}
```
Resolves SR-12290
Resolves rdar://problem/59874355
Previously we were bailing early on encountering
an optional chain in the key path. However this
could cause us to miss invalid components further
down the line. Instead, set a flag and force the
key path to be read-only if we encountered an
optional chain.
Resolves SR-12519.
Argument-to-Parameter mismatch handles conformance failures
related to arguments, so the logic in `MissingConformanceFailure`
which wasn't entirely correct is now completely obsolete.
Resolves: rdar://problem/56234611
This commit changes `getArgumentExprFor` to take
a ConstraintLocator argument from which to find
the argument list. This lets us properly handle
the case where we have a key path subscript
locator. In addition, this commit renames the
member to `getArgumentListExprFor` to make it
clear we're returning the argument list expression
rather than a single argument.
Resolves SR-11562.
Change `associateArgumentLabels` to take a locator
argument to enable the recording of argument
labels for individual key path components. Then
move the association of argument labels for
subscripts to `addSubscriptConstraints`, and plumb
through the argument labels for key path subscript
components.
This then allows us to correctly ignore choices
with mismatching argument labels while solving in
certain cases.
Resolves SR-11438.
Since this kind of failure is really a conversion failure, let's
inherit from `Contextual{Mismatch, Failure}` which also helps with
storage for from/to types and their resolution.
Also let's use original types involved in conversion to form
this fix, which helps to perserve all of the original sugar.
Previously in situations like:
```swift
protocol P {}
struct S<T: P> {
var value: T
}
_ = S(value: 42)
```
Diagnostic has reported a problem as related to "reference" to `init`
but the failing generic type requirement belongs to `S`, so a
better diagnostic in such case should mention `generic struct S`.
Currently only valid way to form keypath subscript is to use `keyPath:`
label in subscript invocation, so let's avoid adding keypath overload
choice to every subscript lookup and instead only add it when it could
potentially match.
This among other things greatly helps diagnostics because sometimes
`keypath application` becomes the only choice even although it's
not really viable, which impedes member reference diagnostics.
Introduce a fix to detect and diagnose situations when omitted
generic arguments couldn't be deduced by the solver based on
the enclosing context.
Example:
```swift
struct S<T> {
}
_ = S() // There is not enough context to deduce `T`
```
Resolves: rdar://problem/51203824
Detect situations where key path doesn't have capability required
by the context e.g. read-only vs. writable, or either root or value
types are incorrect e.g.
```swift
struct S { let foo: Int }
let _: WritableKeyPath<S, Int> = \.foo
```
Here context requires a writable key path but `foo` property is
read-only.
Currently `getPotentialBindingsForRelationalConstraint` doesn't
respect the fact that type of key path expression has to be a
form of `KeyPath`, instead it could eagerly try to bind it to
`Any` or other contextual type if it's only available
information.
This patch aims to fix this situation by filtering potential
bindings available for type variable representing type of
the key path expression.
Resolves: SR-10467
