When we encounter unsafe code in `if let x`, we would produce a Fix-It
that would change it to the ill-formed `if let unsafe x`. Improve
tracking of the expressions that are synthesized for the right-hand
side of these conditions, so that we can produce a Fix-It that turns
this into the proper
if let x = unsafe x
Fixes rdar://147944243.
The issue is that the shorthand if let syntax injects an implicit
expression: https://github.com/apple/swift/pull/40694/ in ParseStmt and
that the 'diagnoseUnhandledAsyncSite' explicitly avoids reporting errors
in implicit expressions.
This change is that we don't mark the implicit declref code emitted by
the `if let prop` as implicit anymore, and this way the reporting works
out as expected.
Added some tests covering this as well as properly erroring out for the
nonexistent syntax of shortand + awaiting which doesn't exist, and we
properly error on it.
Resolves rdar://126169564
When using shorthand syntax for optional binding,
if the variable we are binding is accessed asynchronously,
provide an insertion fixIt of the form: ' = await (identifier)'.
Previously, we would suggest only adding the 'await'
which resulted in an error since the identifier is required.
We now mark some DeclRefExpr and LookupExprs as implicitly async
during typechecking, depending on whether they appear in a context
that is only performing a read / get operation, and whether they
are cross-actor operations.
also resolves rdar://72403401 by improving the error messages
(no more vague "'await' in async context" when its clearly a call!)
The `try await` ordering is both easier to read and indicates the order
of operations better, because the suspension point occurs first and
then one can observe a thrown error.
Currently, we don't have a fix-it to insert 'async', so I've marked those places
as not expecting a fix-it, until someone goes and implements that (rdar://72313654)
When an 'async let' initializer can throw, any access to one of the
variables in the 'async let' can also throw, so require such accesses
to be annotated with 'try'.
Customize diagnostics when an 'await' is missing in an 'async let'
initializer. While here, fix the coverage checking so we also diagnose
a missing 'try'.
The initializer of an 'async let' is executed as a separate child task
that will run concurrently with the main body of the function. Model
the semantics of this operation by wrapping the initializer in an
async, escaping autoclosure (representing the evaluation of the child
task), and then a call to that autoclosure (to
This is useful both for actor isolation checking, which needs to treat
the initializer as executing in concurrent code, and also (eventually)
for code generation, which needs to have that code in a closure so
that it can be passed off to the task-creation functions.
There are a number of issues with this implementation producing
extraneous diagnostics due to this closure transformation, which will
be addressed in a follow-up commit.
Extend effects checking to ensure that each reference to a variable
bound by an 'async let' is covered by an "await" expression and occurs
in a suitable context.
We need to preserve the DiagnoseErrorOnTry bit stored in the Context when
exiting a ContextScope. Otherwise, we fail to produce a diagnostic if the
'try' expression pushes an intertwining Context, such as a string interpolation
or 'await'.
Fixes <https://bugs.swift.org/browse/SR-13654>, <rdar://problem/69958774>.
Fix the parsing of await/try/try?/try! so that the two can be nested
(e.g., `await try f()` or `try await f()`).
Then, fix the effects checking logic to preserve all throws-related
information under an `await`, and preserve all async/await-related
information under `try`/`try?`/`try!`.
Add a number of tests, and fix 'await' handling for string
interpolations as well.
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.
