Open CGNonofr opened 3 years ago
HI @CGNonofr
The intent of 96600de was to workaround the issue where generating changesets for all the actions took too long on large projects. The design is such that we expect for the client to issue the Command
specified to the server so the server can compute and push the changes back to the client when this command is executed (omnisharp/executeCodeAction
). This workaround works on a couple of clients, emacs-lsp
and nvim
, IIRC. Is there something in vscode LSP client or w.r.t. this workaround that makes it unable to execute this Command
?
The proper support for delayed code action resolution was added in 3.16#codeAction_resolve. We are waiting for the #2044 PR to be merged before we can start using it in omnisharp-roslyn
.
Hi @razzmatazz
It seems that not providing the edit
field at all (instead of an empty object) should be fine
I might not know the context, but I see the code is checking (short-circuiting) on the presence of the actual edit
object too, in the line above, so providing it with a null or even undefined value would still not fix anything, right?
This function is not called if edit
is undefined:
FYI @CGNonofr -- I have added a PR that does away with omnisharp/executeCodeAction
and uses the new "Standard" codeAction/resolve
functionality introduced in LSP 3.16 which should fix this issue..
Thanks 👍 I'll give it a try!
I just tried the v1.37.15 and the issue still doesn't seem to be fixed
Here an example of a serialized
CodeAction
response provided by omnisharp-roslyn:Refering to the documentation,
edit
should either beundefined
or of typeWorkspaceEdit
but in the provided example, it's an empty object.
vscode then doesn't consider it as a
CodeAction
and then think it's a legacyCommand
instead of aCodeAction
, starting from here, nothing is workingIt seems related to https://github.com/OmniSharp/omnisharp-roslyn/blob/ebabfb88bebd2989bc5348f9c022241314f064b1/src/OmniSharp.LanguageServerProtocol/Handlers/OmniSharpCodeActionHandler.cs#L102 but I don't know much C#
In was probably broken in https://github.com/OmniSharp/omnisharp-roslyn/commit/96600de10ba16caed0379b1439d1cf5ff382e468#diff-8b5480f9e5910e05693e4a02d4ab416f6b006ec30673dea7bc16e2b919ab9f37L97