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.
Introduce 'TypeCheckSingleASTNode' mode that only type checks single body
element and dependent necessities (i.e. referencing ValueDecls and their
dependencies).
Renamed swift::typeCheckAbstractFunctionBodyAtLoc() to
swift::typeCheckASTNodeAtLoc(DeclContext *, SourceLoc). That type checks
innermost 'ASTNode' at the location. Also, 'TypeCheckSingleASTNode' mode
skips type checking any "body" of the node (i.e. BraceStmt elements for
function body, if statement body, closure body, etc.)
Added on-demand type checking using it:
- VarDecl in TapExpr
- ParamDecl in ClosureExpr
- Return type of ClosureExpr
- Binding value in control statements
(e.g. ForEachStmt, SwitchStmt, DoCatchStmt, etc.)
rdar://problem/63932852
To better preserve source compatibility, teach the constraint
solver to try both the new forward scanning rule as well as the
backward scanning rule when matching a single, unlabeled trailing
closure. In the extreme case, where the unlabeled trailing closure
matches different parameters with the different rules, and yet both
produce a potential match, introduce a disjunction to explore both
possibilities.
Prefer solutions that involve forward scans to those that involve
backward scans, so we only use the backward scan as a fallback.
After the TypeLocs were removed here, the TypeRepr from the IsExpr was
the only thing providing access to syntactic information from the parent
IsExpr. In order to support this, it was possible to construct a bizarre
ConditionalCheckedCastExpr that contained both semantic and syntactic
information. This doesn't comport with the rest of the casting nodes,
which force you to pick one or the other.
Since we're rewriting an IsExpr into a EnumIsCaseExpr, let's just stash
the syntactic information there. This unblocks a bit of cleanup.
Reverse the polarity of the "checked in context" bit for ClosureExpr
to "separately checked", which simplifies the AST walker logic (to
"should we walk separately type-checked closure bodies?") and
eliminates single-expression closures as a separate case to consider.
Rather than using various "applied function builder" and "is single
expression body" checks to determine whether a closure was
type-checked in its enclosing expression, record in the closure
expression whether it actually *was* type-checked as part of its
enclosing expression.
Introduce a statement visitor that applies a particular solution to
the body of a closure. This matches the mechanism used by function
builders (and is similar to how we handle expressions in general),
simplifying the logic for handling
conversion-to-void-returning-closures and
conversion-from-Never-returning-bodies. It is a stepping stone for
type inference of multi-statement closures.
This restores getSourceRange() on DefaultArgumentExpr after it was removed in
https://github.com/apple/swift/pull/31184.
It was originally removed to solve the issues it was causing when computing the
source range of its parent TupleExpr. To account for trailing closures we walk
back through the tuple's arguments until one with a valid location is found,
which we use as the end location. If the last argument was a DefaultArgumentExpr
though that meant the end loc would end up being the tuple's start location, so
none of the tuple's other arguments were contained in its range, triggering an
ASTVerifier assertion. Source tooling and diagnostics don't care about default
arg expression locations as nothing can reference them, but their locations are
output in the debug info. Added a regression test to catch that in future, and
updated TupleExpr::getSourceRange() to ignore them when computing the end loc.
Resolves rdar://problem/63195504.
that allows arbitrary `label: {}` suffixes after an initial
unlabeled closure.
Type-checking is not yet correct, as well as code-completion
and other kinds of tooling.
Accept trailing closures in following form:
```swift
foo {
<label-1>: { ... }
<label-2>: { ... }
...
<label-N>: { ... }
}
```
Consider each labeled block to be a regular argument to a call or subscript,
so the result of parser looks like this:
```swift
foo(<label-1>: { ... }, ..., <label-N>: { ... })
```
Note that in this example parens surrounding parameter list are implicit
and for the cases when they are given by the user e.g.
```swift
foo(bar) {
<label-1>: { ... }
...
}
```
location of `)` is changed to a location of `}` to make sure that call
"covers" all of the transformed arguments and parser result would look
like this:
```swift
foo(bar,
<label-1>: { ... }
)
```
Resolves: rdar://problem/59203764
Also extend returned object from simplify being an expression to
`TrailingClosure` which has a label, label's source location and
associated closure expression.
