search

seblj / roslyn.nvim

Roslyn LSP plugin for neovim
MIT License
11 stars 6 forks source link

Lsp stops when selecting Keyword inside xml comment #7

Open BurkeStrang opened 4 days ago

BurkeStrang commented 4 days ago

This seems to happen only in xml comments. Here is the error I see in LspLog. Afterwards the Lsp is no longer active. Not a huge deal but still odd nonetheless.

[ERROR][2024-06-28 19:00:01] ...lsp/handlers.lua:619 "[LanguageServerHost] System.InvalidOperationException: Missing handler for default\n at Microsoft.CommonLanguageServerProtocol.Framework.RequestExecutionQueue`1.ProcessQueueAsync() in /_/src/LanguageServer/Microsoft.CommonLanguageServerProtocol.Framework/RequestExecutionQueue.cs:line 211"

FailedToGetDataFromRoslyn

seblj commented 4 days ago

I am not able to reproduce this. Do you have a minimal repro of a project I can test this in?

seblj commented 3 days ago

I ran into this when looking into this: #9

Will see if I can figure something out

seblj commented 2 days ago

It was really hard to debug this... If you disable nvim-cmp in your config, do you still have the same issue?

EDIT:

I wrote a bit more about what I believe to be the core of the issue(s) in #9, so I will just paste it here as well:

I think the server is sending data which is wrong, in response to a completionItem/resolve request from neovim. This seems to cause nvim-cmp to do something (I have no idea yet what) that in turn makes the server panic...

If I use vim.lsp.completion which is built in to neovim (which is by design far less feature rich than nvim-cmp), it doesn't seem to cause the server to panic. However, it also doesn't insert the snippet as I expect. Reading the spec, it looks like the implementation of vim.lsp.completion "correctly" does not insert the snippet.

I will see if I am able to put of time to investigate more and eventually raise an issue on the server repo, but I cannot guarantee it, and I also am not sure if this will fix everything.

Ideally, using nvim-cmp and accepting the completion shouldn't cause the server to throw an exception, but I also wouldn't blame nvim-cmp (if it even is because of nvim-cmp), because since the response seems to be "wrong", I don't think this is something that nvim-cmp should account for.

So I will be closing this issue, so if you want potential updates, you can subscribe to the other issue, and I will write my findings there if/when I get time to investigate this.

seblj commented 2 days ago

Another update... So I am pretty sure that this is a bug in roslyn... I have no idea how it works in vscode, since I have now pinpointed where and why the exception happens, and it looks hardcoded, so I have really no idea how it works in vscode...

I have tried a couple of times to compile the language server to debug it there, but I haven't managed to do it yet. I will at least probably open an issue later where I explain the issue, and hopefully someone who is able to compile the project, can fix this. Maybe I can send a PR with a draft of how I think it can work.

In the meantime, I am thinking about implementing a major hack that intercepts the workspace/executeCommand handler, to not make the server panic at least, because that was really annoying