-
Notifications
You must be signed in to change notification settings - Fork 412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trailing comma implementation #2515
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some initial thoughts. My biggest comment is that we should implement the disambiguation between an additional condition element and the body using lookahead instead of by modifying the tree.
@ahoppen I've updated the implementation for conditionals to use a much simpler lookahead approach |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. The approach is the right one, I think. Getting the lookahead logic right is the key building block here, I think and we are on a very good track. I needed to bang my head really hard to come up with counterexamples, those are very contrived and maybe we can ignore them.
@ahoppen I've fixed minor problems with parseArgumentListElements and updated parseConditionList and atStartOfStatementBody implementations to address our conversation. I've also updated the tests and included some substructure assertions to ensure that the expected block is parsed as the statement body. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we’re on the final stretch for this PR. Thanks for your continued work on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice. Looking good to me 👍🏽
I would still like to hear a second opinion from @rintaro on the implementation.
Could you let me know the plan for other comma separated lists like func parameter list, tuple type, generic paremeter/argument list etc? |
I just suggested to keep the PR as-is for now and implement trailing closures for other constructs in a follow-up PR (#2515 (comment)). I’ve already spent considerable time reviewing this PR and it’s easier review-wise if we can consider the implications of trailing commas for other constructs in a separate PR. |
That's right. The current proposal and implementation includes tuples, functions parameter/argument list and |
BTW @ahoppen thank you so much for all the help and patience while reviewing this PR and sorry for all the troubles. That's my first time trying to contribute to the language and whatever the outcome I'm happy with all that I've learned. |
Sources/SwiftParser/Statements.swift
Outdated
// If the current token is at the start of a line, it is most likely a statement body. The only exceptions are: | ||
if withLookahead({ $0.atStartOfStatementBody() }) { | ||
// If a statement body starts after this on, we actually have a closure followed by the statement body e.g. | ||
// if true, { true } | ||
// { | ||
// print("body") | ||
// } | ||
return false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry if I missed the previous discussion, but do we really care this case? Closure alone cannot be a condition. it must be used/called some way (e.g. call it, or make it a part of a sequence expression). This example case is ambiguous, it can be missing ()
after { true }
or missing ()
after { print("body") }
. I don't think it's worth to lookahead again unless there's any strong reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that's a odd case but today that's a valid condition and the parser reports a Function produces expected type 'Bool'; did you mean to call it with '()'?
error so without this lookahead there would be a regression.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not a valid condition today, it's just parsed as a condition expression and diagnosed in type checker. Since it's invalid anyway, I wouldn't consider it's a regression even if we don't parse it as a closure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't feel comfortable changing existing behavior and as a user I consider the type checker diagnostic more helpful because is probably more close to the user intention.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can add at(.leftBrace)
before the withLookahead
to avoid actually looking ahead if not necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current behavior makes sense before the trailing comma support. There was no ambiguity. But supporting trailing comma introduces some ambiguity, for example, I believe the user intention is that { return true }
is the body in the following case:
func test() -> Bool {
if
condition1,
condition2,
{
return true
}
{ print("something") }
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I took I time from this PR and missed your last answer. That's a really good counterexample. Honestly, I'm good with either behavior, whichever has a consensus so this can move forward. Could you weight in @ahoppen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @rintaro.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will change then and also resolve the conflicts with main branch.
I don't see implementation/tests for functions parameter list. e.g. from your proposal
Am I missing anything? |
To be clear I'm not arguing that this PR should include parameter list support. I just want to make sure I'm not missing anything, and know the plan. |
I think I didn't add this test case because arguments and parameters are parsed by the same |
Parameters are parsed with |
Now that's strange because I never touched this functions but if I add your example as a test case |
That's... concerning (for current parser) 😅 FWIW |
I think |
Yeah, I mean we've just discovered a bug in the current parser. We should disallow it unless |
I've update swiftlang/swift#71975 implementation to match this PR. |
One last thing: Could you squash your commits? It makes for a nicer Git history https://github.com/apple/swift-syntax/blob/main/CONTRIBUTING.md#authoring-commits Other than that, there’s anything to be done from my side. I would like to wait for @rintaro’s approval as well though. |
@rintaro do you have any more to add before I squash the commits? |
@swift-ci Please test |
@rintaro I had forget to format the source code after I merged with main, sorry. I think it will pass all the checks now. |
@swift-ci Please test |
@swift-ci Please test Windows |
…ard/while conditions
37ac9f5
to
376ddbb
Compare
@ahoppen done! |
@swift-ci please test |
@swift-ci please test windows |
This is a prototype implementation for Allow trailing comma in tuples, arguments and if/guard/while conditions gated behind
-enable-experimental-feature TrailingComma
.