At the moment, if there is an error in the `switch` statement expression or if the `{` is missing, we return `nullptr` from `parseStmtSwitch`, but we consume tokens while trying to parse the `switch` statement. This causes the AST to not contain any nodes for the tokens that were consumed while trying to parse the `switch` statement.
While this doesn’t cause any issues during compilation (compiling fails anyway so not having the `switch` statement in the AST is not a problem) this causes issues when trying to complete inside an expression that was consumed while trying to parse the `switch` statement but doesn’t have a representation in the AST. The solver-based completion approach can’t find the expression that contains the completion token (because it’s not part of the AST) and thus return empty results.
To fix this, make sure we are always creating a `SwitchStmt` when consuming tokens for it.
Previously, one could always assume that a `SwitchStmt` had a valid `LBraceLoc` and `RBraceLoc`. This is no longer the case because of the recovery. In order to form the `SwitchStmt`’s `SourceRange`, I needed to add a `EndLoc` property to `SwitchStmt` that keeps track of the last token in the `SwitchStmt`. Theoretically we should be able to compute this location by traversing the right brace, case stmts, subject expression, … in reverse order until we find something that’s not missing. But if the `SubjectExpr` is an `ErrorExpr`, representing a missing expression, it might have a source range that points to one after the last token in the statement (this is due to the way the `ErrorExpr` is being constructed), therefore returning an invalid range. So overall I thought it was easier and safer to add another property.
Fixes rdar://76688441 [SR-14490]
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]
Fixe a couple of bugs in libSyntax parsing found by enabling `-verify-syntax-tree` for `%target-build-swift`:
- Fix parsing of the `actor` contextual keyword in actor decls
- Don't build a libSyntax tree when parsing the availability macro
- The availability macro is not part of the source code and doesn't form a valid Swift file, thus creation of a libSyntax tree is completely pointless and will fail
- Add support for parsing `@_originallyDefinedIn` attributes.
- Add support for parsing `#sourceLocation` in member decl lists
- Add support for effectful properties (throwing/async getters/setters)
- Add support for optional types as the base of a key path (e.g. `\TestOptional2?.something`)
- Allow platform restrictions without a version (e.g. `_iOS13Aligned`)
We were only keeping track of `RawSyntax` node IDs to incrementally transfer a syntax tree via JSON. However, AFAICT the incremental JSON transfer option has been superceeded by `SyntaxParseActions`, which are more efficient.
So, let’s clean up and remove the `RawSyntax` node ID and JSON incremental transfer option.
In places that still need a notion of `RawSyntax` identity (like determining the reused syntax regions), use the `RawSyntax`’s pointer instead of the manually created ID.
In `incr_transfer_round_trip.py` always use the code path that uses the `SyntaxParseActions` and remove the transitional code that was still using the incremental JSON transfer but was never called.
We support a special DefaultArgumentKind::NilLiteral, but it was only
used for synthesized and imported default arguments as well.
Let's also use it for parsed default arguments that are exactly 'nil',
so that rethrows checking can special-case them.
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
In particular, we were unconditionally dropping argument labels on accessors; now we only do that for property accessors, not subscript accessors.
Doing this unconditionally causes ClangImporter failures when a method parameter is called “subscript” (really!), so this behavior is enabled only by the caller’s request.
From my point of view, a type that contains a code completion token can still be parsed as a type and as such, `canParseType` should return `true` for e.g. `#^COMPLETE^#` or `SomeType.#^COMPLETE^#`.
Changing this fixes an issue that caused no type completions to be shown inside a enum case decl.
Fixes rdar://71984715
The end location of an attribute used to point to the next token after the attribute's content, which is the closing parenthesis in valid Swift code. But when the parenthesis is missing, it points to the next token, which is most likely no longer part of the attribute.
Fix by parsting the closing parenthesis (conditionally) first and using the location of last token parsed for the attribute (`PreviuosLoc`) as the attribute range's end location.
Resolves rdar://64304839
Propagate parsed type attributes to the TypeAttributes structure, so they
persist in the AST and can be processed by the type checker. Move the
"unknown attribute" diagnostic for custom attributes on types into
the type checker.
Extend the parsing of custom attributes to apply to types. Improve the
lookahead for the arguments so we don't arbitrarily consume the parameter
list of a function type as an attribute argument, or consume a tuple type
as the attribute argument.
Doesn't actually change behavior, because after parsing the custom
attribute on a type, we reject it as an unknown attribute.
Assuming that we don't typecheck a deserialized module, we don't
actually need the ExplicitCompletionHandlerIndex. We used this flag to
determine whether we could trust the number stored in the handler index
or just take the last parameter of the function we're attached to.
Since we only typecheck it before serialization, we can safely check
that the completion handler location is valid before choosing whether we
should trust it or not.
This patch replaces the @hasAsyncAlternative attribute with
@completionHandlerAsync. The @completionHandlerAsync attribute takes the
function decl name of the async function and optionally the index of the
completion hander parameter in the function that it's attached to.
If the completion handler index is not provided, it's assumed to be the
last parameter in the parameter list.
We resolve the async function while typechecking the attribute. Before
resolving, we verify that the function the attribute is attached to
isn't async, that it has enough parameters to at least have the
indicated completion handler referenced by the index, that the
completion handler is an escaping non-auto-closure function that returns
Void.
The async function declaration resolution isn't perfect yet, but I want
to get this patch up and we can refine it later. It pulls all of the
delcs with the specified declname in the same context as the
function that the attribute is attached to. Going through that list, it
keeps any that are async functions. If there are none, we emit an error
saying that there are no viable functions, if there are multiple we emit
an error saying that the decl name is ambiguous, and if there is one
function, we keep that as the resolve async function declaration.
This does not take into account the data types of the completion handler
or the async function. There are some complexities to making this
mapping. Here are the pieces:
- If the completion handler takes a single data type, the async
function should return that type. (easy case)
- If the completion handler takes a `Result<T, Error>`, the async
function is a throwing function that returns a T. (Medium difficulty)
- If the completion handler looks like `(T?, Error?) -> Void`, we have
an ambiguous situation between the following async functions:
- func foo() async throws -> T
- func foo() async throws -> T?
That is, we cannot tell whether the `T?` in the completion handler is
optional because it will be nil on an error, or if it is intended to
be optional.
This can be done later if it becomes a problem.
For backtracking scopes that are never cancelled, we can completely disable the SyntaxParsingContext, avoiding the creation of deferred nodes which will never get recorded.
We have finally reached our goal of optimising deferred node creation
for SyntaxTreeCreator. Instead of creating dedicated deferred nodes and
copying the data into a RawSyntax node when recording, we always create
RawSyntax nodes. Recording a deferred node is thus a no-op, since we
have already created a RawSyntax node. Should a deferred node not be
recorded, it stays alive in the SyntaxArena without any reference to it.
While this means, we are leaking some memory for such nodes, most nodes
do get recorded, so the overhead should be fine compared to the
performance benefit.
The getData and getRecordedOrDeferredNode methods broke the move-only semantics of ParsedRawSyntaxNode because it allowed retrieving the data without resetting it.
Change most uses to use takeData or takeRecordedOrDeferredNode instead of the get methods.
To retrieve the children of a ParsedRawSyntaxNode, we still need a way to access the OpaqueSyntaxNode for inspection by the SyntaxParseActions without resetting it. For this, we still maintain a method with the semantics of getData, but it’s now called getUnsafeOpaqueData to make sure it’s not accidentally used.
By now ParsedRawSyntaxNode does not have any knowledge about deferred
node data anymore, which frees up SyntaxParseActions (and, in
particular its sublass SyntaxTreeCreator) to perform optimisations to
more efficiently create and record deferred nodes.
Essentially all ParsedRawSyntaxNode types have a range associated with
them, so let's just store it in a dedicated field with a common getter.
Additionally, this cleans up the recorded storage to just contain an
OpaqueSyntaxNode. When deferred nodes are being handled by
SyntaxParseActions, we can use this OpaqueNode storage to store either
recorded or deferred node data, which is left to be interpreted by the
SyntaxParseAction.
This is a multi-commit effort to push the responsibility of deferred
node handling to the SyntaxParseActions which have more detailed
knowledge of their requirements on deferred nodes and might perform
additional optimisations. For example, the SyntaxTreeCreator can always
create RawSyntax nodes (even for deferred nodes) and decide to simply
not use them, should the deferred nodes not get recorded.
Instead of having a heap-allocated RefCountedBox to store a SyntaxData's
parent, reference-count SyntaxData itself. This has a couple of
advantages:
- When passing SyntaxData around, only a pointer needs to be passed
instead of the entire struct contents. This is faster.
- We can later introduce a SyntaxDataRef, which behaves similar to
SyntaxData, but delegates the responsibility that the parent stays
alive to the user. While sacrificing guaranteed memory safety, this
means that SyntaxData can then be stack-allocated without any
ref-counting overhead.
Small peformance improvement: Token is larger than a pointer and not
modified in the performance-criticial TokenReceivers, so we can pass
it by reference.
