Skip to content
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

Fix more postfix pound if scenarios #402

Merged
merged 8 commits into from Apr 11, 2023

Conversation

DavidBrunow
Copy link
Contributor

@DavidBrunow DavidBrunow commented Sep 17, 2022

Demonstrates the issue in #392 and provides a potential fix. The fix feels fragile but from what I understand from the syntax tree I'm not sure how to make it less fragile.

My previous pull request only looked up the tree to see if an ancestor was a postfix pound if but this is not sufficient to format properly because a child node having a postfix pound if ancestor does not always mean that that child is nested inside of the postfix pound if. This change traverses back down the tree to ensure that the child node is nested properly.

While typing that out I might have had an epiphany about a better way to solve this, if so I'll update. Either way I'd like to get the test scenarios out there to document those failures.

var this: Syntax? = Syntax(node)

while this?.parent != nil {
if this?.is(TupleExprElementSyntax.self) == true {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This handles the scenario in this test

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the fragile part which I dislike. It handles the scenario in that test fine, but what other scenarios are there that this does not handle, or that this breaks?

@DavidBrunow
Copy link
Contributor Author

DavidBrunow commented Sep 17, 2022

While typing that out I might have had an epiphany about a better way to solve this, if so I'll update. Either way I'd like to get the test scenarios out there to document those failures.

This did not pan out. My thought was "why don't we just look for the right ancestor instead of the postfix if config ancestor?" But from what I can tell, the tree for a postfix if config looks something like this:

PostfixIfConfigExprSyntax -> IfConfigClauseSyntax -> IfConfigClauseListSyntax

Given this example:

  EmptyView()
    .padding([.vertical])
    #if os(iOS)
      .iOSSpecificModifier()
    #endif

The top level is the PostfixIfConfigExprSyntax, so an ancestor of .padding([.vertical]) is a PostfixIfConfigExprSyntax so I don't see a way to differentiate which things are inside the if config clause without going up to an ancestor and back down to a child again.

I simplified this so we don't have to go back down the syntax tree..

#if os(iOS)
.iOSSpecificModifier()
#endif
.commonModifier()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not handled properly by these changes because I didn't think to try adding this until I was creating this pull request. Will look into how to solve this but wanted to have it in this pull request so I didn't forget to mention it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you had any luck with this one? For consistency we'd definitely like if the #if aligns with the preceding . and then the contents are indented one more level.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have not yet, things at work got really busy soon after I created this. I'll take another look at it soon.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took me a bit longer than I expected to get back to this. I think this latest commit works as intended. Let me know if I misunderstood.

I don't love the implementation I landed on so I'l be looking to improve it if I can.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happier where this is now. Would appreciate any and all feedback :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@allevato Friendly ping for awareness, not urgency, here since it took me so long to get back to this. I think it is behaving how you described now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay; I lost track of this one. These results look great, thanks for getting all these cases working so well!

@DavidBrunow
Copy link
Contributor Author

DavidBrunow commented Sep 17, 2022

PostfixIfConfigExprSyntax -> IfConfigClauseSyntax -> IfConfigClauseListSyntax

I had this bit a little wrong, I believe this is correct:

PostfixIfConfigExprSyntax -> IfConfigDeclSyntax -> (IfConfigClauseSyntax || IfConfigClauseListSyntax)

Based upon this, I was able to simplify the implementation.

@DavidBrunow
Copy link
Contributor Author

This should probably be two different pull requests, I'm happy to break them up if others agree.

#if os(iOS)
.iOSSpecificModifier()
#endif
.commonModifier()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay; I lost track of this one. These results look great, thanks for getting all these cases working so well!

@allevato allevato merged commit 2fde6d7 into apple:main Apr 11, 2023
@DavidBrunow DavidBrunow deleted the fixMorePostfixPoundIfs branch April 12, 2023 12:25
allevato added a commit to allevato/swift-format that referenced this pull request Jun 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants