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.
We previously were not properly handling the diagnostics for using an rvalue implicit member on the left hand side of an assignment. This adds the proper handling and extends it for member chains.
Instead of creating the type variable for the unresolved member chain at the location of the last member, we now create it at the associated UnresolvedMemberChainResultExpr.
Previously, when the final element of a chain was a ForceValueExpr, the chain result type got caught up in the logic used to allow ForceValueExprs to properly infer lvalue types. By separating the result type variable from the last member of the chain, we make sure to keep that logic focused only on ForceValueExpr.
If reference collection discovered at least `ErrorExpr` in the body
of a closure, let's fail constraint generation only if it's a
single-statement closure, decision about multi-statement closures
should be delayed until body is opened.
This helps code completion because `ErrorExpr` could belong to
a statement unrelated to a completion, so it wouldn't affect
its correctness in any way.
Fix a regression introduced by moving the type checking of closure
captures into the constraint system. The pattern-type optimization for
initializations was causing inference of a double-optional where there
shouldn't be one, manifesting in a failure involving implicitly
unwrapped optionals and `weak self` captures.
Fixes rdar://problem/67351438.
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.
when we have an optional type. This uncovered an error with unresolved member lookup where we allowed an unresolved value member constraint to fail if lookup failed in an optional type wrapping a type variable.
This resolves SR-13357.
The change to resolve ObjC #keyPath expression components caused some source
breakage as they are now being checked for availability issues. This change
updates availability checking to demote error diagnostics to warnings
within #keyPath expressions. There were cases in the source compat suite where
unavailble properites were used in #keyPath expressions, but they caused no
issues at runtime because the properties' ObjC runtime name was still correct
(e.g. the same as its renamed-to property in Swift).
Unlike \keypath expressions, only the property components of #keypath
expressions were being resolved, so index wouldn't pick up references for their
qualifying types.
Also fixes a code completion bug where it was reporting members from the Swift
rather than ObjC side of bridged types.
Resolves rdar://problem/61573935
Unlike \keypath expressions, only the property components of #keypath
expressions were being resolved, so index wouldn't pick up references for their
qualifying types.
Also fixes a code completion bug where it was reporting members from the Swift
rather than ObjC side of bridged types.
Resolves rdar://problem/61573935
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.
Rather than type-checking captures as separate declarations during
pre-check, generate constraints and apply solutions to captures in
the same manner as other pattern bindings within a constraint
system.
Fixes SR-3186 / rdar://problem/64647232.
This approach, suggested by Xiaodi Wu, provides better source
compatibility for existing Swift code, by breaking ties in favor of the
existing Swift semantics. Each time the backward-scan rule is needed
(and differs from the forward-scan result), we will produce a warning
+ Fix-It to prepare for Swift 6 where the backward rule can be
removed.
