Due to https://github.com/apple/swift/pull/36552, parsing the code completion token as a type inside a generic parameter list no longer fails. Instead, it consumes the code completion token as a type identifier. However, since `parseExprIdentifer` does not return a `ParserStatus`, the information whether a code completion token was consumed gets lost, causing `setCodeCompletionDelayedDeclState` to not be called and thus no code completion results show up.
To resolve this, make `parseExprIdentifier` return its `ParserStatus` through a `ParserResult`.
Fixes rdar://76335452 [SR-14432]
When completing within an InOutExpr like `&foo.<complete>`, we were forming a
CodeCompletionExpr with a base when parsing the content of the InOutExpr and
storing it in CodeCompletionCallbacksImpl::CodeCompleteTokenExpr. When the
result of that parse contained a code completion though, we were dropping the
sub-expression completely and forming an empty code completion result in place
of the inout expression, which resulted in later code inserting a code
completion expression with no base into the AST. The solver based completion
was later asking for the type of the code completion and its base using the
expression stored in CodeCompletionCallbacksImpl::CodeCompleteTokenExpr, but
that never ended up in the AST so we hit an assertion about the expression not
have a type in the formed solutions.
Resolves rdar://75366814
For backtracking scopes that are never cancelled, we can completely disable the SyntaxParsingContext, avoiding the creation of deferred nodes which will never get recorded.
The way in which we detected an "async" in expression context broke
some well-formed code that used "async" as a variable. Narrow the
check to only cases where the code will be ill-formed with "async" as
an identifier.
Always parse `async` and `await`, allowing the definition and use of
asynchronous functions without the "experimental concurrency" flag.
Note that, at present, use of asynchronous functions requires one to
explicitly import or link against the `_Concurrency` library. We'll
sort this out in a follow-up change.
Tracked by rdar://73455330.
This is again a transitional state before SyntaxParsingContext hands
the responsibility over to SyntaxTreeCreator and from there to
SyntaxParseActions.
This is an intermediate state in which the lexer delegates the
responsibility for trivia lexing to the parser. Later, the parser will
delegate this responsibility to SyntaxParsingContext which will hand it
over to SyntaxParseAction, which will only lex the pieces if it is
really necessary to do so.
By replacing the 'async' with 'await' in the parser, we avoid the issue
of cascading errors as the compiler gets more and more confused by what
it's reading. Instead, everything mostly passes and we just emit the one
error message.
One caveat that I hadn't taken into account before was that we could
have a function called "async", in which case we don't want to replace
the "async" keyword with "await".
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.
Following on from updating regular member completion, this hooks up unresolved
member completion (i.e. .<complete here>) to the typeCheckForCodeCompletion API
to generate completions from all solutions the constraint solver produces (even
those requiring fixes), rather than relying on a single solution being applied
to the AST (if any). This lets us produce unresolved member completions even
when the contextual type is ambiguous or involves errors.
Whenever typeCheckExpression is called on an expression containing a code
completion expression and a CompletionCallback has been set, each solution
formed is passed to the callback so the type of the completion expression can
be extracted and used to lookup up the members to return.
Code completion used to avoid forming single expression closures/function
bodies when the single expression contained the code completion expression
because a contextual type mismatch could result in types not being applied
to the AST, giving no completions.
Completions that have been migrated to the new solver-based completion
mechanism don't need this behavior, however. Rather than trying to guess
whether the type of completion we're going to end up performing is one of
the ones that haven't been migrated to the solver yet when parsing, instead
just always form single-expression closures/function bodies (like we do for
regular compilation) and undo the transformation if and when we know we're
going to perform a completion kind we haven't migrated yet.
Once all completion kinds are migrated, the undo-ing code can be removed.
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() }
}
}
For example, the completion below would trigger error recovery within the
closure, which we recover from by skipping to the first inner closure's right
brace. The fact that we recovered though, was not recorded. The closure is
treated as still being an error, triggering another recovery after it that
skips over the 'Thing' token, giving a lone closure expression, rather than a
call.
CreateThings {
Thing { point in
print("hello")
point.#^HERE^#
}
Thing { _ in }
}
This isn't an issue for code completion when the outer closure is a regular
closure, but when it's a function builder, invalid elements result in no types
being applied (no valid solutions) and we end up with no completion results.
The fix here is removing the error status from the parser result after the
initial parser recovery.
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.
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.
This allows the syntax parser library and SwiftSyntax to successfully
parse code using this experimental feature without requiring an API
to pass compiler flags into the parser.
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
