Open MiliAxe opened 8 months ago
MiliAxe
commented
8 months ago Edit: Using an older version like 1.39.8 Does not give such an error.
Seems like this error started appearing from 1.39.9 onward.
In v1.39.9, this error keeps being spammed. unlike v1.39.10 that goes away if ignored
kidkych
commented
8 months ago Also having the exact same issue. Any updates? I am on v1.39.10 as well
JoeRobich
commented
8 months ago Edit: Using an older version like 1.39.8 Does not give such an error.
Seems like this error started appearing from 1.39.9 onward.
In 1.39.9 we took an updated build of the csharp-language-server-protocol libraries. It is likely a regression there. Has anyone been able to determine which request is causing the error? If so, we could open an issue at https://github.com/OmniSharp/csharp-language-server-protocol/issues
StreenJiang
commented
7 months ago Still has the same issue in 1.39.10
Jonatanc05
commented
7 months ago Exact problem here. Except I only get it on a huge and old net3.1 project and, well, could be unrelated but the LSP spams errors, starting with the using statements:
The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?)
leblocks
commented
7 months ago Same issue in omnisharp 1.39.10 and neovim 0.9.4 on windows
teast
commented
7 months ago I too am having this problems from time to time.
I tried to do some debug printout in neovim and this is my finding (maybe someone here can make sense of them?)
in rpc.lua there is an method "create_read_loop" that has following while loop:
while true do
local headers, body = parse_chunk(chunk)
if headers then
if body == nil then
print("BODY IS NIL IN create_read_loop");
end
if body == "null" then
print("BODY is: \"null\", chunk: " .. dump(chunk));
end
handle_body(body)
chunk = ''
else
break
end
endAs you can see I have added two if-cases for my debug print.
The second one is hit when this error is generated. I think the error could be cause by parse_chunk(chunk) returning the string "null" to body.
The chunk that caused "null" to be returned looked like this (note, I have redacted some part):
{
"jsonrpc": "2.0",
"method": "o#/projectchanged",
"params": {
"MsBuildProject": {
"AssemblyName": "REDACTED",
"Configuration": "Debug",
"IntermediateOutputPath": "obj\\Debug\\net6.0\\",
"IsExe": true,
"IsUnityProject": false,
"OutputPath": "bin\\Debug\\net6.0\\",
"Path": "C:\\projects\\REDACTED\\tests\\REDACTED.csproj",
"Platform": "AnyCPU",
"ProjectGuid": "00000000-0000-0000-0000-000000000000",
"SourceFiles": [
" *** REDACTED *** "
],
"TargetFramework": ".NETCoreApp,Version=v6.0",
"TargetFrameworks": [
{
"FriendlyName": ".NETCoreApp",
"Name": ".NETCoreApp",
"ShortName": "net6.0"
}
],
"TargetPath": "C:\\projects\\REDACTED\\tests\\REDACTED\\bin\\Debug\\net6.0\\REDACTED.dll"
}
}
}
KiLLeRRaT
commented
5 months ago Same issue in omnisharp 1.39.11 and neovim 0.9.5 on Arch
sajadspeed
commented
5 months ago Same here.
omas313
commented
5 months ago Having the same issue. System Information: OmniSharp v1.39.11, Neovim v0.9.5, Pop!_OS 22.04 LTS
Hannover1992
commented
5 months ago Error executing vim.schedule lua callback: /opt/neovim/share/nvim/runtime/lua/vim/lsp/util.lua:1157: Cursor position outside buffer stack traceback: [C]: in function 'nvim_win_set_cursor' /opt/neovim/share/nvim/runtime/lua/vim/lsp/util.lua:1157: in function 'jump_to_location' /opt/neovim/share/nvim/runtime/lua/vim/lsp/handlers.lua:412: in function 'handler' /opt/neovim/share/nvim/runtime/lua/vim/lsp.lua:1393: in function '' vim/_editor.lua: in function <vim/_editor.lua:0> Press ENTER or type command to continue
◍ omnisharp
OmniSharp language server based on Roslyn workspaces. This version of Omnisharp requires dotnet (.NET 6.0) to be
installed.
installed version v1.39.11
homepage https://github.com/OmniSharp/omnisharp-roslyn
languages C#
categories LSP
executables omnisharp
↓ LSP server configuration schema (press enter to collapse)
This is a read-only overview of the settings this server accepts. Note that some settings might not apply to neovim.Same Problem, but i am fresh in omnisharp, perhaps bad config
Kleppa
commented
5 months ago Same issue.
OmniSharp: 1.39.11 EndevourOs: 2023.08.05
Noodle-Bug
commented
5 months ago Can confirm still happening on v1.39.11 but not v1.39.8 for me
InfinytRam
commented
5 months ago same issue occurs on v1.39.11 using Linux.
jknopp
commented
4 months ago Same issue occurs on v1.39.11 using MacOS, NeoVim 0.9.5.
616b2f
commented
4 months ago This issue seems related: https://github.com/OmniSharp/omnisharp-roslyn/issues/2594
superbrobenji
commented
4 months ago can confirm still an issue
Ani-Sako
commented
4 months ago Still an issue on omnisharp 1.39.10, neovim 0.9.5 on Windows 11.
Rolling back to omnisharp 1.39.8 fixes the issue (if using Mason run :MasonInstall omnisharp@1.39.8).
sergiuser1
commented
4 months ago Still an issue on omnisharp 1.39.10, neovim 0.9.5 on Windows 11.
Rolling back to omnisharp 1.39.8 fixes the issue (if using Mason run :MasonInstall omnisharp@1.39.8).
You need an extra v in the version:
:MasonInstall omnisharp@v1.39.8
Green0wl
commented
3 months ago same issue. omnisharp v1.39.11. NVIM v0.9.5. 6.6.9-arch1-1.
JosefLitos
commented
2 months ago The simplest workaround is to edit /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:383 and add not decoded to the first check of handle_body() →
if not ok or not decoded then...
VanAdcox
commented
2 months ago Still an issue omnisharp v1.39.11. NVIM v0.9.5
mrphil2105
commented
2 months ago I have the same issue. I am also using Omnisharp v1.39.11 and Neovim v0.9.5 on Arch Linux.
sajadspeed
commented
2 months ago Does anyone want to solve this problem? It seems that everyone has this problem.
StreenJiang
commented
2 months ago Does anyone want to solve this problem? It seems that everyone has this problem.
Yes of course I want, but for me, I don't really know neovim apis, I don't know lua, and I don't have much time to dig into it for now, so what I can do is to wait for a hero to save us hahahaha
svermeulen
commented
2 months ago In my case going back to 1.39.8 didn't help, but going back to 1.38.2 did. This also fixed another issue I was having where code actions stopped working.
pluma9
commented
1 month ago In my case going back to 1.39.8 didn't help, but going back to 1.38.2 did. This also fixed another issue I was having where code actions stopped working.
I am having this issue in 1.39.9, 1.39.8, 1.38.2 only in large codebases. The error says "No code actions". I have temporarily switched to csharp-ls.
rudiejd
commented
1 month ago I too am having this problems from time to time.
I tried to do some debug printout in neovim and this is my finding (maybe someone here can make sense of them?)
in rpc.lua there is an method "create_read_loop" that has following while loop:
while true do local headers, body = parse_chunk(chunk) if headers then if body == nil then print("BODY IS NIL IN create_read_loop"); end if body == "null" then print("BODY is: \"null\", chunk: " .. dump(chunk)); end handle_body(body) chunk = '' else break end endAs you can see I have added two if-cases for my debug print.
The second one is hit when this error is generated. I think the error could be cause by parse_chunk(chunk) returning the string "null" to body.
The chunk that caused "null" to be returned looked like this (note, I have redacted some part):
{ "jsonrpc": "2.0", "method": "o#/projectchanged", "params": { "MsBuildProject": { "AssemblyName": "REDACTED", "Configuration": "Debug", "IntermediateOutputPath": "obj\\Debug\\net6.0\\", "IsExe": true, "IsUnityProject": false, "OutputPath": "bin\\Debug\\net6.0\\", "Path": "C:\\projects\\REDACTED\\tests\\REDACTED.csproj", "Platform": "AnyCPU", "ProjectGuid": "00000000-0000-0000-0000-000000000000", "SourceFiles": [ " *** REDACTED *** " ], "TargetFramework": ".NETCoreApp,Version=v6.0", "TargetFrameworks": [ { "FriendlyName": ".NETCoreApp", "Name": ".NETCoreApp", "ShortName": "net6.0" } ], "TargetPath": "C:\\projects\\REDACTED\\tests\\REDACTED\\bin\\Debug\\net6.0\\REDACTED.dll" } } }
I'm not able to reproduce this on the current nightly build of neovim. Here's the script I used
local body =
[[
{
"jsonrpc": "2.0",
"method": "o#/projectchanged",
"params": {
"MsBuildProject": {
"AssemblyName": "REDACTED",
"Configuration": "Debug",
"IntermediateOutputPath": "obj\\Debug\\net6.0\\",
"IsExe": true,
"IsUnityProject": false,
"OutputPath": "bin\\Debug\\net6.0\\",
"Path": "C:\\projects\\REDACTED\\tests\\REDACTED.csproj",
"Platform": "AnyCPU",
"ProjectGuid": "00000000-0000-0000-0000-000000000000",
"SourceFiles": [
" *** REDACTED *** "
],
"TargetFramework": ".NETCoreApp,Version=v6.0",
"TargetFrameworks": [
{
"FriendlyName": ".NETCoreApp",
"Name": ".NETCoreApp",
"ShortName": "net6.0"
}
],
"TargetPath": "C:\\projects\\REDACTED\\tests\\REDACTED\\bin\\Debug\\net6.0\\REDACTED.dll"
}
}
}
]]
local ok, decoded = pcall(vim.json.decode, body, { luanil = { object = true } })
print(vim.inspect(decoded))and that parses fine 🤔 but I still get this error when I open a project. I'll try to add some debugging code into my local neovim runtime and see what line is causing decoded = nil for me.
nagaohiroki
commented
1 week ago This issue seems to have occurred after this commit. 51c5e00c57469d1f9ef7bcb7e5b5ca662355159b
nagaohiroki
commented
4 days ago If I change 51c5e00c57469d1f9ef7bcb7e5b5ca662355159b back to b2e64c6006beed49460f063117793f42ab2a8a5c in CSharpDiagnosticWorkerWithAnalyzers.cs, nvim runs smoothly and the error goes away.
Changing from AnalyzerWorkQueue to AsyncAnalyzerWorkQueue seems to cause an error in nvim.
But even after changing ac7b9b8509356e39583de2b9fdf363005e6c8595(latest) CSharpDiagnosticWorkerWithAnalyzers.cs to b2e64c6006beed49460f063117793f42ab2a8a5c omnisharp-roslyn still doesn't work.
Issue Description
I am encountering an error when using the OmniSharp Language Server Protocol (LSP) integration in Neovim. The error message I receive is as follows:
Steps to Reproduce
Expected Behavior
I expect the OmniSharp LSP integration to work without errors and to correctly handle symbol detection and LSP-related requests.
Actual Behavior
The error mentioned above is encountered but normal usage of language server is achievable if the error is ignored. it appears to be related to the decoding of JSON data within the LSP integration.
System Information
Log Files
LspLog:
Thank you for your help in addressing this problem.