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

Remove the legacy trivia workaround. #646

Merged
merged 1 commit into from
Oct 3, 2023

Conversation

allevato
Copy link
Member

This was added when SwiftSyntax changed its behavior regarding trailing trivia -- previously it was only whitespace but now it includes all trivia up to the next newline, including comments (block comments and end-of-line comments). This workaround rewrote trivia to correspond to the old layout before processing the syntax tree further so that we didn't have to overhaul all the rules at the time.

However, it isn't good for long-term maintenance for swift-format to be written with assumptions about trivia that aren't consistent with how syntax trees Straight Outta The Parser are formed.

@allevato
Copy link
Member Author

allevato commented Oct 2, 2023

cc @dylansturg

This gets rid of some tech debt so in the future we won't run into issues with how SwiftSyntax's trivia differs from what swift-format expects it to be.

} else {
syntaxLocation = node?.startLocation(converter: context.sourceLocationConverter)
syntaxLocation = nil
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you recall why node is optional? It seems weird to allow a finding without a location.

Copy link
Member Author

Choose a reason for hiding this comment

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

If I remove the optionality here, we break OrderedImports where there are code paths that pass an optional TokenSyntax to this function.

From a quick glance, my guess is that those code paths only run when the token is actually non-nil, but untangling that is probably best done in a separate PR.


// We treat block comments after the semicolon slightly differently from end-of-line
// comments. Assume that an end-of-line comment should stay on the same line when a
// semicolon is removed, but if we have something like `f(); /* blah */ g()`, assume that
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a test for this? It looks like the new test has the statement with a block comment on a line without any other statements.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good call, added a test.

This was added when SwiftSyntax changed its behavior regarding trailing
trivia -- previously it was only whitespace but now it includes all
trivia up to the next newline, including comments (block comments and
end-of-line comments). This workaround rewrote trivia to correspond to
the old layout before processing the syntax tree further so that we
didn't have to overhaul all the rules at the time.

However, it isn't good for long-term maintenance for swift-format to be
written with assumptions about trivia that aren't consistent with how
syntax trees Straight Outta The Parser are formed.
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.

2 participants