Add diagnostic to move 'async' and 'throws' in 'ArrowExpr' in front of '->' #881
Conversation
|
I'm fine with adding |
| // unexpectedAfterArrow and inserting the corresponding effects modifier as | ||
| // missing into the ArrowExprSyntax. This reflect the semantics the user | ||
| // originally intended. | ||
| var effectModifiersAfterArrow: [RawTokenSyntax] = [] |
There was a problem hiding this comment.
This only handles throws async and not eg.throws throws async. I've put up a very partial PR for function signatures (#889). Any thoughts on something like that instead? There's quite a few places we'll want to change this 😅 (if we decide this is in fact something the parser should handle).
There was a problem hiding this comment.
I know. I was thinking that we should probably allow effects specifiers in any order in the parser.
ahoppen
force-pushed
the
ahoppen/throws-after-arrow-expr
branch
from
59d0170 to
8bf7809
Compare
|
@swift-ci Please test |
ahoppen
force-pushed
the
ahoppen/throws-after-arrow-expr
branch
from
8bf7809 to
72085ee
Compare
|
@swift-ci Please test |
|
@swift-ci Please test |
…oken This makes sure we don’t drop newlines or comments when removing tokens.
ahoppen
force-pushed
the
ahoppen/throws-after-arrow-expr
branch
from
72085ee to
a4088dd
Compare
|
@swift-ci Please test |
|
@swift-ci Please test macOS |
| """, | ||
| diagnostics: [ | ||
| // TODO: Old parser expected error on line 5: protocol methods must not have bodies | ||
| // TODO: Old parser expected error on line 6: protocol methods must not have bodies | ||
| ] | ||
| """ |
There was a problem hiding this comment.
Why was this removed?
There was a problem hiding this comment.
SwiftSyntax uses the same nodes for functions inside protocols and structs. Since protocols have optional bodies, function bodies are also optional for functions in in structs in SwiftSyntax. This has two advantages:
- It reduces the nodes we need in SwiftSyntax (we only need a single one and not one for protocols and one for all the other types)
.swiftinterfacefiles also have optional function bodies (even for functions in structs). This way, we can parse.swiftinterfacefiles without any problems.
The idea is that the missing function body will be diagnosed by ASTGen further down in the compilation pipeline instead of by the parser.
There was a problem hiding this comment.
I appreciate the detailed clarification!
After parsing the
->for anArrowExpr, eat trailingthrowsorasyncand include them as unexpected nodes after the->. This is safe because the expression after->cannot start withthrowsorasync.This changes the syntax nodes to allow unexpected tokens after the last expected token. Previously @rintaro had concerns about unexpected nodes at the end of a node because this make it even more ambiguous where the unexpected tokens should be placed, but it’s super convenient for this diagnostic, so allowed it again.