Format the swift-syntax repository using swift-format #1113
Conversation
|
The styling with the trailing |
| case // '0'-'9' | ||
| 48, 49, 50, 51, 52, 53, 54, 55, 56, 57: |
There was a problem hiding this comment.
This is worse IMO. Is something weird going on because of the comment trivia here?
There was a problem hiding this comment.
@allevato Do you know if this is a bug in swift-format or whether this formatting is intentional?
We can always turn off formatting for some of these lines with // swift-format-ignore as well.
There was a problem hiding this comment.
This looks like a bug; we have some logic that tries to determine whether a comment is an end-of-line comment or some other inline comment so that we can do something that looks reasonable with it, and it looks like it's falling over in this case. At the very least we shouldn't be dedenting that next line.
| lastElement = self.parseSequenceExpressionElement(flavor, | ||
| forDirective: forDirective, | ||
| pattern: pattern) | ||
| lastElement = self.parseSequenceExpressionElement( | ||
| flavor, | ||
| forDirective: forDirective, | ||
| pattern: pattern | ||
| ) |
There was a problem hiding this comment.
Not sure how I feel about always requiring the latter here. Sometimes the former is better. I don't feel super strongly either way though.
| let unexpectedAfterArrow = | ||
| effectModifiersAfterArrow.isEmpty | ||
| ? nil | ||
| : RawUnexpectedNodesSyntax( | ||
| elements: effectModifiersAfterArrow.map { RawSyntax($0) }, | ||
| arena: self.arena | ||
| ) |
There was a problem hiding this comment.
IMO worse but I probably would have use an if here so... 🤷
| return (other.baseAddress! <= self.baseAddress! && | ||
| self.baseAddress! + count <= other.baseAddress! + other.count) | ||
| return (other.baseAddress! <= self.baseAddress! && self.baseAddress! + count <= other.baseAddress! + other.count) |
There was a problem hiding this comment.
@allevato is this one intended because of the line length, or a bug?
There was a problem hiding this comment.
This is because the current implementation only allows breaking on the left-hand side of an infix operator (with the exception of assignment operators, which may only break on the right). So we remove the break after the && and then continue laying out the rest of the line, which never breaks again because of the high column limit.
With a lower line length, this would "auto-correct" because we would see that the && and the text after it doesn't fit and we would force the break before the && instead, but the high column limit is interfering here.
There was a problem hiding this comment.
Ah so:
return (other.baseAddress! <= self.baseAddress!
&& self.baseAddress! + count <= other.baseAddress! + other.count)
would have remained split?
There was a problem hiding this comment.
Is there a setting for that? I personally like them the other way 😅
There was a problem hiding this comment.
There isn't a configuration option for that today. It probably wouldn't be difficult to add, but to date we haven't had the resources to maintain a large matrix of configurability options and make sure they all work well together, so we mainly prioritize the default style that we use within Google. (PRs welcome 😄)
ahoppen
force-pushed
the
ahoppen/format
branch
from
b9e695f to
a347108
Compare
ahoppen
force-pushed
the
ahoppen/format
branch
from
a347108 to
d41d166
Compare
|
@swift-ci Please test |
1 similar comment
|
@swift-ci Please test |
ahoppen
force-pushed
the
ahoppen/format
branch
from
d41d166 to
8d55566
Compare
|
@swift-ci Please test |
ahoppen
force-pushed
the
ahoppen/format
branch
from
8d55566 to
8004b0c
Compare
|
@swift-ci Please test |
ahoppen
force-pushed
the
ahoppen/format
branch
from
8004b0c to
c7a5eb7
Compare
|
@swift-ci Please test |
This does not format the generated files because it’s harder to debug generator changes if the newly generated files need to be formatted to get a meaningful diff.
This PR is intended to spark the discussion whether we want to format all files in SwiftSyntax using
swift-format. If we agree that we should do this, I will add a verification pass in CI to assure that all files are formatted.I personally think that we should do this. In most cases I agree with the new format and not having to care about formatting when writing the code is a big win IMO.
rdar://103251585