Add shared cursorInfo infrastructure and forEach-to-forIn code action

[MoonMao42]

Closes #2584
Closes #2509

Adds SharedCursorInfo so code action providers can share a single cursorInfo request. SyntaxCodeActionProvider.codeActions(in:) is now async, and the scope object (renamed to CodeActionScope) is created once in codeAction() and passed to all retrieve methods.

Also adds a code action to convert .forEach to for-in loops, as the first provider that uses this.

Before:

names.forEach { name in
  print(name)
}

After:

for name in names {
  print(name)
}

Only handles closures with explicit named parameters ($0 shorthand is not supported).

[rintaro]

Looks pretty good already!

[rintaro]

I think this whole actor can be generalized as something like:

actor LazyTask<Success: Sendable> {
  private let operation: @Sendable () async throws -> Success

  init(_ operation: @escaping @Sendable () async throws -> Success) {
    self.operation = operation
  }

  private lazy var task: Task<Success, any Error> = Task {
    try await operation()
  }

  var value: Success {
    get async throws {
      try await task.value
    }
  }
}

Maybe we already have something like it?

[rintaro]

Suggested change

	// Copyright (c) 2014 - 2024 Apple Inc. and the Swift project authors
	// Copyright (c) 2014 - 2026 Apple Inc. and the Swift project authors

[rintaro]

Is SyntaxVisitor really relevant? For example, for:

1️⃣func test() {
  2️⃣foo.bar.3️⃣forEach4️⃣ { item in
    print(item)
  }5️⃣
}6️⃣

I think we should only offer the code action when the curosr/selection is 2️⃣..<4️⃣, 2️⃣..<5️⃣, 3️⃣..<3️⃣, 3️⃣..<4️⃣, and 3️⃣..<5️⃣.
I think using a visitor and returning .visitChildren for every failure case makes it available for 1️⃣..<6️⃣ or even for the entire source file.
Please add test cases as needed.

[rintaro]

Could you explain what is a case we can't convert it to for-in?

I understand having try? outside the forEach call expression is not easy:

try? foo.forEach { ...; try ...; }

to:

do {
  for item in foo { ...; try ...; }
} catch { /*ignore*/ }

But I'm not sure having try in the closure body prevents anything.

[rintaro]

I don't think this handles anonymous closure parameters. $0 does not appear in the closure parameter syntax tree.

It would be great this also rewrites $0. I.e. rewrite

foo.forEach {
  print($0)
}

with

for element in foo {
  print(element)
}

It's not super obvious whether we can use element though, we should check if it's not already used in the body.

[rintaro]

I don't think we should dig into any non-StmtSyntax.
Are there any cases where return in an expression or decl escapes the surrounding function scope?

[rintaro]

I don't see you addressed this? Also applies to other visitors/rewriters. Please avoid dig into unnecessary nodes.

[MoonMao42]

Addressed — all three visitor/rewriter classes (ClosureEligibilityVisitor, ReturnToContinueRewriter, DollarZeroRewriter) now consistently skip the same five scope-introducing constructs: FunctionDeclSyntax, InitializerDeclSyntax, DeinitializerDeclSyntax, ClosureExprSyntax, AccessorBlockSyntax.

[rintaro]

Please add this file and SharedCursorInfo.swift to https://github.com/swiftlang/sourcekit-lsp/blob/main/Sources/SwiftLanguageService/CMakeLists.txt

[rintaro]

Suggested change

	// Copyright (c) 2014 - 2024 Apple Inc. and the Swift project authors
	// Copyright (c) 2014 - 2026 Apple Inc. and the Swift project authors

[rintaro]

What about ClosureShortParameterSyntax? Ideally the conversion should be:
foo.forEach { item in ... } -> for item in foo { ... }
foo.forEach { (item) in ... } -> for item in foo { ... }
foo.forEach { (item: Ty) in ... } -> for item: Ty in foo { ... }

[rintaro]

func retrieveCodeActions(_:providers:) below is now unused.

[rintaro]

I think retrieveSyntaxCodeActions was added even if wantedActionKinds exist. Am I missing something?

[rintaro]

Could you use a different name?
We already have LazyValue with different semantics here https://github.com/swiftlang/sourcekit-lsp/blob/main/Sources/SwiftExtensions/LazyValue.swift

[MoonMao42]

Done, thanks for the review.

[rintaro]

Ah sorry I didn't think about what information is in the cursor-info result when I was suggesting the ranges to offer actions.

We'd like to avoid requesting non-shared cursorInfo in textDocument/codeAction request. Could you remove this? And I think it's okay for now to suggest this action only when the cursor is on forEach.

I.e. for

      1️⃣func test() {
        let array = [1, 2, 3]
        2️⃣array.reversed().3️⃣forEach4️⃣ { item in
          print(item)
        }5️⃣
      }6️⃣

The action is active only for 3️⃣..<3️⃣ and 3️⃣..<4️⃣.

[MoonMao42]

Makes sense — the action now activates only when the cursor/selection is exactly on the forEach token, so shared cursorInfo at the request position works.

[rintaro]

If it's only active at forEach, the check can be something like:

guard
  let token = node.as(TokenSyntax.self),
  token.text = "forEach"
  let memberName = token.parent?.as(DeclReferenceExprSyntax.self),
  let memberAccessExpr = member.parent?.as(MemberAccessExprSyntax.self),
  memberAccessExpr.declName.id == memberName.id,
  let callExpr = memberAccessExpr.parent?.as(FunctionCallExprSyntax.self),
  callExpr.calledExpression.id == memberAccessExpr,
else {
  return nil
}

let closure: ClosureExprSyntax?
...

[MoonMao42]

Done — replaced with selectedForEachToken(in:) that validates directly against the request range positions.

[rintaro]

forEach(_:) is available on Sequence, so could you name this sequence instead of collection?

[rintaro]

And this can be scope.cursorInfo()

[rintaro]

Could you make a single function/visitor checking both? So we can check the eligibility in single pass.

[rintaro]

I don't think we need to separate function for this.
Also, could you avoid inserting every identifier in the Set, we're only interested in identifiers starting with element

[MoonMao42]

Done — containsIdentifier(named:in:) now checks on demand instead of collecting all names.

[rintaro]

I don't see you addressed this? Also applies to other visitors/rewriters. Please avoid dig into unnecessary nodes.

[rintaro]

It's getting close!
Just a few nit-picky edge case handling suggestions.

[rintaro]

So I realized this is not enough for cases like

items.forEach { item in
  for elem in item.elements {
    if condition(elem) {
      return
    }
  }
  // ...
}

In this case, we need a label on the rewritten for-in:

ITEM: for item in items {
  for elem in item.elements {
    if condition(elem) {
      continue ITEM
    }
  }
  // ...
}

That said, I'm fine with ignoring such cases for this PR. But in that case, could you add FIXME and file an issue for that?

[rintaro]

Any type declarations too. i.e. struct, class, enum, etc.

[rintaro]

Rare edge case:

arr.forEach { [] in
  print($0)
}

In this case signature is non-nil.
Even more edge case:

arr.forEach { [foo = bar] in
  print($0, foo)
}

I guess we should rewrite this like

do {
  let foo = bar 
  for element in arr {
    print(element, foo)
  }
}

But it's too much effort.
I'm fine with just rejecting (not offering the action) for closures with capture list.

[rintaro]

I'm not sure this is what swift-format suggests. Could you run swift format -i -r . at the package top-level directory? Otherwise the test will fail.

[rintaro]

Does scope.innermostNodeContainingRange not work?

[MoonMao42]

tokenForRefactoring shifts the cursor to the previous token at exact token boundaries, so innermostNodeContainingRange resolves to . instead of forEach when the cursor is at the start of forEach. selectedForEachToken bypasses this by matching against the raw request position.

[rintaro]

@swift-ci Please test

[rintaro]

@MoonMao42 Could you rebase on the current main and fix the build issue?
Also macOS failure indicates the formatting is still off. Try swift format -i -r . again right before pushing.

[rintaro]

Ah, I think try await shouldn't be here.