Split up the expr list parsing members such that
there are separate entry points for tuple and
argument list parsing, and start using the argument
list parsing member for call and subscripts.
Completing a generic parameter to a nested type `Outer.Nested<#^COMPLETE^#>` crashed when used to initialize a local variable and returned no results when initializing a global variable.
This is because the generic argument parsing logic for nested types inside `parseExprPostfixSuffix` didn’t match that of global types in `parseExprIdentifier`. Make sure they do the same thing semantically.
Fixes rdar://77909679 [SR-14627]
This commit essentially consistes of the following steps:
- Add a new code completion key path component that represents the code completion token inside a key path. Previously, the key path would have an invalid component at the end if it contained a code completion token.
- When type checking the key path, model the code completion token’s result type by a new type variable that is unrelated to the previous components (because the code completion token might resolve to anything).
- Since the code completion token is now properly modelled in the constraint system, we can use the solver based code completion implementation and inspect any solution determined by the constraint solver. The base type for code completion is now the result type of the key path component that preceeds the code completion component.
This resolves bugs where code completion was not working correctly if the key path’s type had a generic base or result type. It’s also nice to have moved another completion type over to the solver-based implementation.
Resolves rdar://78779234 [SR-14685] and rdar://78779335 [SR-14703]
When completing `items.#^COMPLETE^# { $0.content }`, we are stopping parsing of the expression after the code completion token and are thus left with `{ $0.content }` in `parseDeclVar`, which interprets the `{` as the start of an accessor clause, wrapping the entire variable in an accessor decl and thus causing code completion to not show any results.
To avoid this issue, consume any postfix expressions after the code completion token and discard them. This assures that the trailing closure gets consumed before it can be interpreted as an accessor decl.
Fixes rdar://77259087 [SR-14544]
Parse a completion token as an empty parameter name (just like `_`) to
prevent the parser to parse it as an expression and offer completions
for it.
rdar://78798718
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.
