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)
Unwrap `InOutExpr` from all parens until the outermost paren or a tuple
to correctly diagnose calls like `foo(((&bar)))` or `foo(x: (&bar))`,
and suggest a fix-it with moves `&` outside parens.
Resolves: rdar://problem/71356981
Let's consider conditional requirement failure to mean that parent
conformance requirement wasn't satisfied and nothing more, that helps
to disambiguate certain situations and avoid filtering out conditional
failures.
Resolves: rdar://problem/64844584
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.
Instead of failing constraint generation upon encountering
an invalid declaration, let's turn that declaration into a
potential hole and keep going. Doing so enables the solver
to reach a solution and diagnose any other issue with
expression.
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>.
I created a second copy of each test where the output changes
after disabling parser lookup. The primary copy now explicitly
calls the frontend with -disable-parser-lookup and expects the
new diagnostics; the *_parser_lookup.swift version calls the
frontend with -enable-parser-lookup and has the old expectations.
This allows us to turn parser lookup on and off by default
without disturbing tests. Once parser lookup is completely
removed we can remove the *_parser_lookup.swift variants.
We'll need this to get the right 'selfDC' when name lookup
finds a 'self' declaration in a capture list, eg
class C {
func bar() {}
func foo() {
_ = { [self] in bar() }
}
}
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.
If subtyping is allowed for a result type of an implicit member chain,
let's delay binding it to an optional until its object type resolved too or
it has been determined that there is no possibility to resolve it.
Otherwise we might end up missing solutions since it's allowed to
implicitly unwrap base type but it can't be done early - type variable
representing chain's result type has a different l-valueness comparing
to generic parameter of an optional.
This used to work before due to a hack in constraint generator where
unresolved member with arguments would return base type (which
doesn't allow l-value) instead of a result type.
Resolves: rdar://problem/68094328
Generally, casting consistency demands that we be able
to extract anything from an existential that can be put
into that existential. (Which is why the casting spec
requires that casting permit arbitrary injection and
projection of optionals.)
This particular diagnostic prevented optionals from being
projected back out of existentials:
let i: Int?
let a: Any = i // Inject Int? into Any
// Error prevents projecting Int? back out of Any
a as? Int?
This also broke certain uses of Mirror (weak variables get reflected as
optionals stored in Any existentials).
The introduction of forward-scan matching for trailing closures
(SE-0286) failed to account for unresolved member expressions,
sometimes causing a crash in SILGen. Fixes rdar://problem/67781123.
