Assign CodeAction Kind

[kjeremy]

In order to nicely support multiple code actions at a given location we need to fill in the kind field for each action in a hierarchical fashion.

See https://microsoft.github.io/language-server-protocol/specifications/specification-3-15/#textDocument_codeAction and handle_code_action in handlers.rs

See https://code.visualstudio.com/updates/v1_41#_codeactiondisabled which suggests we can append to the builtin strings?

[matklad]

cc @SomeoneToIgnore, this seems(I haven’t read the spec yet) like it might actually cover the import use-case as well?

[SomeoneToIgnore]

I will try it again, but I was unable to get those actions to group by setting that property and enabling the support on the client and the server:

#2716 (comment)

[kjeremy]

@SomeoneToIgnore did you change the titles to unique things too? I would expect that to work but... the LSP isn't exactly obvious sometimes.

[kjeremy]

At the very least this will give us keybinding support https://code.visualstudio.com/docs/editor/refactoring

[SomeoneToIgnore]

Here's what I get with different names and different kinds.
Here's the hacky code I used to get this: https://github.com/rust-analyzer/rust-analyzer/compare/master...SomeoneToIgnore:multiple-actions-test?expand=1#diff-57a6a05c79db4a0461f95762e92206d3

If feels like changing supported actions and code action kinds does nothing, that's why I wonder what I miss.

[kjeremy]

In VSCode if you hit the keybinding for refactoring (ctrl+shift+R) the UI should only return refactors. "ctrl+." should give you both refactors and quickfixes. We can actually use this information to ignore computing code assists on the server side too I think. There is also a kind that can apply all quick fixes to the file (source.fixAll).

If you assign is_preferred and then assign a keybinding you can autofix if an action is marked as a quickfix. It looks like there is currently no grouping at the menu level but I'm pretty sure I saw an issue about it (I'll dig it up).

[kjeremy]

To summarize I think we should do the following:

1. Make code action titles (and associates command titles?) dynamic if possible based on what they will do.
2. Ensure that we can return multiple instances of the same AssistId kind for a given location.
3. Assign the appropriate CodeActionKind to all assists (to start this could just be the default list from the LSP protocol, we don't have to get hierarchical until we think it will change behavior on the client side).
4. Possibly filter the assist computations based on the set passed in the CodeActionContext of the params.
5. Figure out what makes sense for marking an action as preferred.

For filtering (and eventually marking assists as 'non applicable' ie disabled) we should probably know our AssistId list upfront. For figuring out the CodeActionKind we could possibly start with an enum on AssistId and throw a conversion in conv.rs @matklad?

[kjeremy]

As an example: https://github.com/vshaxe/vshaxe/wiki/Code-Actions

[kjeremy]

I was just playing with this and if we return the kinds from the server initialize request we get the refactor and code action menus showing up in vscode.

Filling in the kind field also allows them to show up in the menus as those actions.