Add test cases for parsing closures inside if statement conditions
#2104
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci Please test |
Add a bunch of test cases that verify that SwiftParser accepts closures inside `if` conditions if and only if the C++ parser does.
The only difference is that the C++ parser emits a warning in cases like `if test { $0 } {}`: `Trailing closure in this context is confusable with the body of the statement; pass as a parenthesized argument to silence this warning`. We currently don’t have any infrastructure to emit warnings from SwiftParser and I’m not sure if this warning is really necessary. NFC on whether we need it.
While writing the test cases, I found an issue in `BasicFormat` that adds a newline after the opening `{` of the closure inside these conditions, which causes the closure to get parsed as the statement’s body. Fixed that as well.
Fixes swiftlang#795
rdar://99948919
ahoppen
force-pushed
the
ahoppen/closure-parsing
branch
from
8ba671d to
3a5647b
Compare
|
@swift-ci Please test |
bnbarham
reviewed
Aug 31, 2023
| @@ -607,3 +627,17 @@ fileprivate extension TokenSyntax { | |||
| } | |||
| } | |||
| } | |||
|
|
|||
| fileprivate extension SyntaxProtocol { | |||
| /// Returns this node or the first ancestor that satisfies `condition`. | |||
There was a problem hiding this comment.
We have in SwiftParserDiagnostics and here now. Worth just adding in general?
There was a problem hiding this comment.
I don’t feel happy enough with this API to make it public yet. So I prefer to just have two copies of it for now.
|
|
||
| func testTrailingClosureInGuard() { | ||
| assertParse( | ||
| "guard test 1️⃣{ $0 } 2️⃣else {}", |
There was a problem hiding this comment.
Oh, yes we do. the trailing closure is not really ambiguous in guard statements so we … disallow it there. 🤷🏽
I’m happy to open a conversation about this behavior independently of this issue.
bnbarham
approved these changes
Sep 1, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add a bunch of test cases that verify that SwiftParser accepts closures inside
ifconditions if and only if the C++ parser does.The only difference is that the C++ parser emits a warning in cases like
if test { $0 } {}:Trailing closure in this context is confusable with the body of the statement; pass as a parenthesized argument to silence this warning. We currently don’t have any infrastructure to emit warnings from SwiftParser and I’m not sure if this warning is really necessary. NFC on whether we need it.While writing the test cases, I found an issue in
BasicFormatthat adds a newline after the opening{of the closure inside these conditions, which causes the closure to get parsed as the statement’s body. Fixed that as well.Fixes #795
rdar://99948919