Skip to content

Replace expression in ClosureCaptureSyntax with initializer clause #2763

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

Merged
merged 7 commits into from
Aug 7, 2024

Conversation

MAJKFL
Copy link
Contributor

@MAJKFL MAJKFL commented Jul 29, 2024

This PR adjusts ClosureCaptureSyntax node.

@MAJKFL MAJKFL requested review from ahoppen and bnbarham as code owners July 29, 2024 19:44
Copy link
Member

@ahoppen ahoppen left a comment

Choose a reason for hiding this comment

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

Instead of removing any public API, could you add the existing API signatures as deprecated methods to SwiftSyntaxCompatibility.swift with the most reasonable implementation possible?

Also, could you add the changes to the 601 release notes?

Comment on lines 1709 to 1710
let name: RawTokenSyntax
let initializer: RawInitializerClauseSyntax?
Copy link
Member

Choose a reason for hiding this comment

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

You should be able to hoist the parsing of name out of the if statement and then use self.at(.equal) instead of self.peek(isAt: .equal)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the suggestion. I moved name parsing to before the if statement.

As an interesting artifact, self token will not be remapped to identifier when parsing capture of [self = 123] form. Out of curiosity, was there a particular reason for this remapping? As far as I checked, e.g. in let self = 123 self is classified as a keyword.

@MAJKFL MAJKFL requested review from ahoppen July 30, 2024 08:51
Comment on lines -1170 to -1236
extension ClosureCaptureSyntax {
@available(*, deprecated, renamed: "unexpectedBetweenNameAndEqual")
public var unexpectedBetweenNameAndAssignToken: UnexpectedNodesSyntax? {
get {
return unexpectedBetweenNameAndEqual
}
set {
unexpectedBetweenNameAndEqual = newValue
}
}

@available(*, deprecated, renamed: "equal")
public var assignToken: TokenSyntax? {
get {
return equal
}
set {
equal = newValue
}
}

@available(*, deprecated, renamed: "unexpectedBetweenEqualAndExpression")
public var unexpectedBetweenAssignTokenAndExpression: UnexpectedNodesSyntax? {
get {
return unexpectedBetweenEqualAndExpression
}
set {
unexpectedBetweenEqualAndExpression = newValue
}
}

@available(*, deprecated, renamed: "ClosureCaptureSyntax(leadingTrivia:_:specifier:_:name:_:equal:_:expression:_:trailingComma:_:trailingTrivia:)")
@_disfavoredOverload
public init(
leadingTrivia: Trivia? = nil,
_ unexpectedBeforeSpecifier: UnexpectedNodesSyntax? = nil,
specifier: ClosureCaptureSpecifierSyntax? = nil,
_ unexpectedBetweenSpecifierAndName: UnexpectedNodesSyntax? = nil,
name: TokenSyntax? = nil,
_ unexpectedBetweenNameAndAssignToken: UnexpectedNodesSyntax? = nil,
assignToken: TokenSyntax? = nil,
_ unexpectedBetweenAssignTokenAndExpression: UnexpectedNodesSyntax? = nil,
expression: some ExprSyntaxProtocol,
_ unexpectedBetweenExpressionAndTrailingComma: UnexpectedNodesSyntax? = nil,
trailingComma: TokenSyntax? = nil,
_ unexpectedAfterTrailingComma: UnexpectedNodesSyntax? = nil,
trailingTrivia: Trivia? = nil

) {
self.init(
leadingTrivia: leadingTrivia,
unexpectedBeforeSpecifier,
specifier: specifier,
unexpectedBetweenSpecifierAndName,
name: name,
unexpectedBetweenNameAndAssignToken,
equal: assignToken,
unexpectedBetweenAssignTokenAndExpression,
expression: expression,
unexpectedBetweenExpressionAndTrailingComma,
trailingComma: trailingComma,
unexpectedAfterTrailingComma,
trailingTrivia: trailingTrivia
)
}
}

Copy link
Member

Choose a reason for hiding this comment

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

People might still be relying on these compatibility overloads, so we shouldn’t remove them.

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 added those to SwiftSyntaxCompatibility.swift.

Copy link
Member

Choose a reason for hiding this comment

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

We should continue to offer deprecated compatibility versions of all the old signatures in this file. SwiftSyntaxCompatibility.swift should have a few examples.

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 added those to SwiftSyntaxCompatibility.swift.

Comment on lines 1638 to 1631
public var name: TokenSyntax? {
public var name: TokenSyntax {
Copy link
Member

Choose a reason for hiding this comment

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

Changing name to be non-optional is an API-breaking change because eg. closuereCapture.name?.text will stop compiling. There is no way of making it API-compatible. Could you highlight it in the release notes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for pointing this out. I added a note under "API-Incompatible Changes" in the release notes.

Comment on lines 18 to 20
- `ClosureCaptureSyntax` now has a new node structure.
- Description: `ClosureCaptureSyntax` now has an `initializer` property instead of `equal` and `expression`. Additionally, the `name` property is no longer optional.
- Pull request: https://github.com/swiftlang/swift-syntax/pull/2763
Copy link
Member

Choose a reason for hiding this comment

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

I would move this to the Deprecations section because that’s the way that users are most likely to hit it: They were using it before and now they have a deprecation warning.

New APIs is intended for features that didn’t exist before.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the suggestion. I moved it to the note under "Deprecations".

Copy link
Member

@ahoppen ahoppen left a comment

Choose a reason for hiding this comment

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

Thanks for adding the compatibility layers. Looks good to me 👍🏽

@ahoppen
Copy link
Member

ahoppen commented Jul 31, 2024

@swift-ci Please test

@MAJKFL
Copy link
Contributor Author

MAJKFL commented Aug 1, 2024

The CI failed because we removed the self remapping to identifier earlier in this PR and I didn't add it as a possible kind in CodeGeneration. Should be fixed now.

@ahoppen
Copy link
Member

ahoppen commented Aug 1, 2024

There’s a merge conflict in the release notes now, could you resolve that @MAJKFL?

@MAJKFL
Copy link
Contributor Author

MAJKFL commented Aug 1, 2024

Should be good to go now. Could you please test it @ahoppen?

@ahoppen ahoppen enabled auto-merge (squash) August 1, 2024 22:07
@ahoppen
Copy link
Member

ahoppen commented Aug 1, 2024

@swift-ci Please test

auto-merge was automatically disabled August 2, 2024 07:50

Head branch was pushed to by a user without write access

@MAJKFL
Copy link
Contributor Author

MAJKFL commented Aug 2, 2024

Had to fix failing testConsistentNamingOfChildren test. Seems like ClosureCaptureSyntax was picked up as mostCommonChild over MatchingPatternConditionSyntax because of alphabetical precedence.

@DougGregor
Copy link
Member

@swift-ci please test

@DougGregor
Copy link
Member

@swift-ci please test Windows

1 similar comment
@DougGregor
Copy link
Member

@swift-ci please test Windows

@DougGregor
Copy link
Member

Ah, drat:

/home/build-user/swift-format/Tests/SwiftFormatTests/PrettyPrint/ClosureExprTests.swift:266: error: ClosureExprTests.testClosureCapture : failed - Pretty-printed result was not what was expected - Actual output (+) differed from expected output (-):
 let a = funcCall() { [weak self] (a: Int) in
   return a + 1
 }
 let a = funcCall() {
-  [weak self, weak a = self.b] (a: Int) in
+  [weak self, weak a  =  self.b] (a: Int) in
   return a + 1
 }
 let b = funcCall() {
-  [unowned self, weak delegate = self.delegate!]
+  [unowned self, weak delegate  =  self.delegate!]
   (a: Int, b: String) -> String in
   return String(a) + b
 }

@MAJKFL
Copy link
Contributor Author

MAJKFL commented Aug 2, 2024

Hmm... this is an interesting one. Inside TokenStreamCreator, when visiting ClosureCaptureSyntax node, the method adds spaces around the = token which seem to be not necessary anymore. I was able to fix the failure locally just by removing those two lines of code (which used deprecated by this PR ClosureCaptureSyntax.equal property btw).

override func visit(_ node: ClosureCaptureSyntax) -> SyntaxVisitorContinueKind {
  before(node.firstToken(viewMode: .sourceAccurate), tokens: .open)
  after(node.specifier?.lastToken(viewMode: .sourceAccurate), tokens: .break)
  // before(node.equal, tokens: .break)
  // after(node.equal, tokens: .break)
  if let trailingComma = node.trailingComma {
    before(trailingComma, tokens: .close)
    after(trailingComma, tokens: .break(.same))
  } else {
    after(node.lastToken(viewMode: .sourceAccurate), tokens: .close)
  }
  return .visitChildren
}

Does it mean we need to fix it there? Or do you think there is a way to fix it in this PR and I'm missing something?

@DougGregor
Copy link
Member

DougGregor commented Aug 2, 2024

Hmm... this is an interesting one. Inside TokenStreamCreator, when visiting ClosureCaptureSyntax node, the method adds spaces around the = token which seem to be not necessary anymore. I was able to fix the failure locally just by removing those two lines of code (which used deprecated by this PR ClosureCaptureSyntax.equal property btw).

override func visit(_ node: ClosureCaptureSyntax) -> SyntaxVisitorContinueKind {
  before(node.firstToken(viewMode: .sourceAccurate), tokens: .open)
  after(node.specifier?.lastToken(viewMode: .sourceAccurate), tokens: .break)
  // before(node.equal, tokens: .break)
  // after(node.equal, tokens: .break)
  if let trailingComma = node.trailingComma {
    before(trailingComma, tokens: .close)
    after(trailingComma, tokens: .break(.same))
  } else {
    after(node.lastToken(viewMode: .sourceAccurate), tokens: .close)
  }
  return .visitChildren
}

Does it mean we need to fix it there? Or do you think there is a way to fix it in this PR and I'm missing something?

Yes, I think it's okay to fix it there.

Edit: Argh, I'm not really sure now. Could it be that the now-deprecated equal should produce the node without whitespace? That doesn't seem quite right, either. @ahoppen or @allevato , do either of you have an opinion?

@ahoppen
Copy link
Member

ahoppen commented Aug 6, 2024

Edit: Argh, I'm not really sure now. Could it be that the now-deprecated equal should produce the node without whitespace? That doesn't seem quite right, either. @ahoppen or @allevato , do either of you have an opinion?

The equal property should return the equal token with its trivia because the equal token has trivia attached to it. The compatibility layers are best-effort and this sort of issue might happen because we’re now effectively visiting the equal token twice. We should just fix swift-format like you suggested. @MAJKFL Could you open a PR with that change to swift-format and then we can merge it together with the swift-syntax PR.

@allevato
Copy link
Member

allevato commented Aug 6, 2024

I agree that we should just update swift-format to stop using the compatibility layer nodes. In cases like this where the fundamental structure of a node changes, it's important that we visit the tree in the way that reflects the actual structure.

@ahoppen
Copy link
Member

ahoppen commented Aug 6, 2024

swiftlang/swift-format#790

@swift-ci Please test

@ahoppen ahoppen merged commit 8eaab36 into swiftlang:main Aug 7, 2024
3 checks passed
@MAJKFL MAJKFL deleted the closure-capture-syntax-node-update branch October 16, 2024 11:23
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.

4 participants