Shared `cursorInfo` infrastructure in `SwiftLanguageService.codeAction(_:)`

[rintaro]

Some code actions need type information (via cursorInfo) to determine whether they are applicable to the current selection. Today, there is no shared infrastructure for this, so each implementation would need to request cursorInfo independently.

In general, expensive work for code actions should be deferred to codeAction/resolve. However, for cases where applicability itself depends on semantic information, deferring this check can lead to a poor experience: a code action may appear applicable initially but then fail during resolve.

To address this, we should introduce a shared cursorInfo mechanism for SwiftLanguageService.codeAction(_:), so that all SyntaxCodeActionProviders participating in allSyntaxCodeActions can access it when needed.

A possible direction is to have SyntaxCodeActionScope expose a way to retrieve cursorInfo for the current scope. This should be:

• Lazy: cursorInfo should only be requested if at least one code action actually needs it.
• Shared: multiple providers should reuse the same cursorInfo result rather than issuing duplicate requests.
• Composable with existing flows: we already request cursorInfo in retrieveRefactorCodeActions, so it would be ideal if that result could also be reused in retrieveSyntaxCodeActions.

[MoonMao42]

Would it work to have a SharedCursorInfo actor that lazily caches the cursorInfo task, created once in codeAction() and passed into SyntaxCodeActionScope? Providers call scope.cursorInfo() which awaits the same cached task. SyntaxCodeActionProvider becomes async for this.

The forEach→for-in action from #2566 would then just be a regular entry in allSyntaxCodeActions.

[rintaro]

Yes, that mostly aligns with what I was thinking. And yes SyntaxCodeActionProvider.codeActions(in:) is going to be async.

Maybe SharedCursorInfo actor could be hidden behind SyntaxCodeActionScope. We could then create a SyntaxCodeActionScope in retrieveCodeActions(_:providers:) and pass that to the concrete retrieveXXXCodeActions methods instead of passing the CodeActionRequest.

[MoonMao42]

Quick question on the scope of the refactor: when you said "pass SyntaxCodeActionScope to the concrete retrieveXXXCodeActions methods", did you mean all of them including retrieveRefactorCodeActions, retrieveQuickFixCodeActions, etc.?

SyntaxCodeActionScope currently carries syntax-specific state (syntaxTree, range, innermostNodeContainingRange) that those methods don't use. In my implementation I create SharedCursorInfo in codeAction() and pass it separately to both retrieveSyntaxCodeActions and retrieveRefactorCodeActions, so they share the same lazy cursorInfo without forcing a syntax scope onto non-syntax paths.

[rintaro]

when you said "pass SyntaxCodeActionScope to the concrete retrieveXXXCodeActions methods", did you mean all of them including retrieveRefactorCodeActions, retrieveQuickFixCodeActions, etc.?

Yes.

In my implementation I create SharedCursorInfo in codeAction() and pass it separately to both retrieveSyntaxCodeActions and retrieveRefactorCodeActions, so they share the same lazy cursorInfo without forcing a syntax scope onto non-syntax paths.

That's another option. I just thought having that syntax-specific information available wouldn't really be harmful for the other methods either.
For example, retrieveQuickFixCodeActions currently calls self.latestSnapshot(for: params.textDocument.uri), which could potentially be shared across other retrieveXXXCodeActions as well. By the way, this is already needlessly diverged from retrieveSyntaxCodeActions, which calls documentManager.latestSnapshot(uri) directly.

To be clear, I was just throwing out another option here - I'm not strongly pushing for it. If you think your implementation is clearer, that's totally fine. Feel free to open a PR with it.

[rintaro]

(And thank you for looking into this 🙇‍♂️)