Navigation Menu

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

[SR-5738] Refactoring action to convert to trailing closure #48308

Closed
akyrtzi opened this issue Aug 22, 2017 · 8 comments
Closed

[SR-5738] Refactoring action to convert to trailing closure #48308

akyrtzi opened this issue Aug 22, 2017 · 8 comments
Assignees
Labels
compiler The Swift compiler in itself feature A feature request or implementation good first issue Good for newcomers refactoring Area → source tooling: refactoring source tooling Area: IDE support, SourceKit, and other source tooling

Comments

@akyrtzi
Copy link
Member

akyrtzi commented Aug 22, 2017

Previous ID SR-5738
Radar None
Original Reporter @akyrtzi
Type New Feature
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Source Tooling
Labels New Feature, Refactoring, StarterProposal
Assignee @rintaro
Priority Medium

md5: e5f9ca7e1032a74769619f94fc09552d

Issue Description:

Implement a refactoring action that can change code from:

foo(a: { print(3) })

to:

foo { print(3) }

when applicable

@rintaro
Copy link
Mannequin

rintaro mannequin commented Aug 23, 2017

CC/ @nkcsgexi
I have a couple of questions.

1) Assuming this is CURSOR_REFACTORING, which cursor position should be handled?
For instance, when user want to refactor this:

foo
  .bar(x: { _ in .. })
  .baz(y: { _ in .. })

to:

foo
  .bar { _ in .. }
  .baz(y: { _ in .. })

Where the cursor should be on? Anywhere in range of ".bar(x: {" and "})" ?

2) Is there convenient way to retrieve context info from SemaToken?
When the cursor is on "(", it's Kind is ExprStart and TrailingExpr is just a TupleExpr. Since current SemaToken struct doesn't have any context info, I couldn't detect this TupleExpr is an argument for CallExpr.
Should I extend SemaLocResolver and SemaToken so that it preserves surrounding expressions?

@rintaro
Copy link
Mannequin

rintaro mannequin commented Aug 23, 2017

Or should I make it RANGE_REFACTORING? then handle:

  • Info.ContainedNodes[0] of RangeKind::SingleExpression; or

  • Info.CommonExprParent of RangeKind::PartOfExpression

@akyrtzi
Copy link
Member Author

akyrtzi commented Aug 23, 2017

Where the cursor should be on? Anywhere in range of ".bar(x: {" and "})" ?

I think this make sense, essentially:

  • in the range of the call

  • excluding call arguments, but including the braces of the last closure argument

  • excluding the inner range of the closure

Is there convenient way to retrieve context info from SemaToken? [..] Should I extend SemaLocResolver and SemaToken so that it preserves surrounding expressions?

I think that's a good idea. But instead of keeping track more expressions (which can be arbitrary how many parent expressions you want to look at) I recommend that SemaToken keeps track of the "containing" declaration (e.g. the function that contains the expression). Or perhaps the top-level containing statement. Then have a getParentMap() method that delegates to Expr::getParentMap() to get a map useful for getting the parents in the AST tree.
Also consider that we may need a more generic map that also can provide the parent Stmt of an Expr

@rintaro
Copy link
Mannequin

rintaro mannequin commented Aug 24, 2017

Thank you! I'll try that.

@swift-ci
Copy link
Collaborator

Comment by KacperHarasim (JIRA)

Hi @rintaro, are you working on this or is it available to implement? Thanks for letting me know 🙂

@rintaro
Copy link
Mannequin

rintaro mannequin commented Sep 25, 2017

Hi kacperh (JIRA User), feel free to take this task 🙂
I've partially implemented this, but I'm so busy these days that I can't finish them up until October.

@swift-ci
Copy link
Collaborator

Comment by KacperHarasim (JIRA)

@rintaro Thanks for the answer! Since you have implemented it partially I will find another refactoring task to take. 🙂

@rintaro
Copy link
Mannequin

rintaro mannequin commented Apr 3, 2018

Implemented in #12268

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added feature A feature request or implementation good first issue Good for newcomers compiler The Swift compiler in itself source tooling Area: IDE support, SourceKit, and other source tooling and removed new feature StarterProposal labels Nov 11, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself feature A feature request or implementation good first issue Good for newcomers refactoring Area → source tooling: refactoring source tooling Area: IDE support, SourceKit, and other source tooling
Projects
None yet
Development

No branches or pull requests

3 participants