Error When Attempting to use Go to Definition

[DarrenClevenger]

When I attempt to us go to definition, I get the following error:
Error executing vim.schedule lua callback: /usr/share/nvim/runtime/lua/vim/lsp/util.lua:1047: Cursor position outside buffer stack traceback: [C]: in function 'nvim_win_set_cursor' /usr/share/nvim/runtime/lua/vim/lsp/util.lua:1047: in function 'jump_to_location' /usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:345: in function 'handler' /usr/share/nvim/runtime/lua/vim/lsp.lua:1173: in function '' vim/_editor.lua: in function <vim/_editor.lua:0>

[glvno]

I'm having this problem as well. I got the exact same error using the omnisharp language server, so I'm wondering if the problem is somewhere upstream.

EDIT: Would getting the the definition you're looking for involve decompilation? I think that may be the issue here. Try going to a few different definitions. Go to def works fine for me, I'm noticing, if decompilation is not necessary. See https://github.com/razzmatazz/csharp-language-server/issues/21

[glvno]

If indeed it's decompilation-related, check out https://github.com/Hoffs/omnisharp-extended-lsp.nvim, and if you're still having trouble after getting it up and running, try changing your goto definition bindings from <Cmd>lua vim.lsp.buf.definition()<CR> to <cmd>lua require('csharp_ls_extended').lsp_definitions()<cr>.

For reference: https://github.com/Hoffs/omnisharp-extended-lsp.nvim/issues/2

[razzmatazz]

hey; I think csharp-ls needs to return null by default when go-to-definition points to code-on-metadata.. otherwise we get these funny errors from editors expecting file:// URIs while we pass them csharp://metadata-info uris. I.e. this should probably be hidden under a client features flag.

FYI, there is a nvim extension to support go-to-metadata as mentioned here by @Decodetalkers:

• https://github.com/razzmatazz/csharp-language-server/issues/21#issuecomment-1061683658
• https://github.com/Decodetalkers/csharpls-extended-lsp.nvim

[joalcava]

I have the same problem, for me, it seems like the lsp is only loading the project to which the file belongs, but it is ignoring the other projects in the solution. If I use go to definition on a symbol that belongs to the same project it works fine, but if it is defined in another project (same solution) it returns this error.

[Decodetalkers]

I have the same problem, for me, it seems like the lsp is only loading the project to which the file belongs, but it is ignoring the other projects in the solution. If I use go to definition on a symbol that belongs to the same project it works fine, but if it is defined in another project (same solution) it returns this error.

You can use my extension https://github.com/Decodetalkers/csharpls-extended-lsp.nvim , if you have some problem , I will help you, if your problem is about decompile

[lndr27]

I have the same problem, for me, it seems like the lsp is only loading the project to which the file belongs, but it is ignoring the other projects in the solution. If I use go to definition on a symbol that belongs to the same project it works fine, but if it is defined in another project (same solution) it returns this error.

You can use my extension https://github.com/Decodetalkers/csharpls-extended-lsp.nvim , if you have some problem , I will help you, if your problem is about decompile

I was experiencing the same problem. On a solution with multiple projects "jump to definition" actually tries to open the compiled symbol definition instead of the actual referenced file. I don't know if I'm doing something wrong.

@Decodetalkers, I was able to modify your plugin (thanks, btw) to check for the existence of the file using fd and the symbol name, but since I don't have much experience writing lua (none really, this was my first attempt writing something) and the fact that adding fd creates an external dependency, I thought you might be able to help.

U.find_file_in_pwd = function(symbolName)
    -- Generic classes have (e.g. Repository<T>) have "`1" at the end of symbolName
    symbolName = string.gsub(symbolName, '`1', '')
    symbolName = string.gsub(symbolName, '%.', '/')
    local file = io.popen('fd -I -L -g -p "**/'.. symbolName ..'.*" "`pwd`"')
    local output = file:read('*l')
    file.close()
    return output
end

[razzmatazz]

I was experiencing the same problem. On a solution with multiple projects "jump to definition" actually tries to open the compiled symbol definition instead of the actual referenced file. I don't know if I'm doing something wrong.

this should not happen across projects in a solution.. do you happen to have a single .sln file that csharp-ls tries to load or does it load projects on-by-one -- you can see this on the log (not sure where in nvim)

is there anything special about your project references? do you have the same .net sdk version on both projects? is it the same language (c# / f# / vb?)

[lndr27]

this should not happen across projects in a solution.. do you happen to have a single .sln file that csharp-ls tries to load or does it load projects on-by-one -- you can see this on the log (not sure where in nvim)

You are correct, sir. I think because the default glob pattern to search for the root folder included both *.csproj and *.sln, it didn't bother to search up the directory tree to find the solution folder. I changed it to just "*.sln" and it started working. root_dir = util.root_pattern('*.sln', '.git')

I think it's pretty common to have the .sln file one folder up from the .csproj file.

[lispercat]

Similar issue. When I try to go to definition to a third-party library (say System) it gives me

Error executing vim.schedule lua callback: /usr/local/share/nvim/runtime/lua/vim/lsp/util.lua:1798: index out of range
stack traceback:
    [C]: in function '_str_byteindex_enc'
    /usr/local/share/nvim/runtime/lua/vim/lsp/util.lua:1798: in function 'locations_to_items'
    ...nvim/lazy/telescope.nvim/lua/telescope/builtin/__lsp.lua:197: in function 'handler'
    /usr/local/share/nvim/runtime/lua/vim/lsp/client.lua:687: in function ''
    vim/_editor.lua: in function <vim/_editor.lua:0>