In trying to debug why clangd lsp isnt working in a repo, i noticed some errors in the log file(~/.cache/nvim/lsp.log)
some of the errors are mentioning file not found at location. .local/share/nvim/lspinstall/cpp/clangd/lib/clang/12.0.0/include
but this is from the old lsp i was using from a different lsp install manager plugin.
ive since switched to williamboman/nvim-lsp-installer
which puts it here .local/share/nvim/lsp_servers/clangd/clangd_13.0.0/lib/clang/13.0.0/include/
is there some cached data somewhere that i need to delete to get it to start reading in the new lsp location?
I would recommend clearing your runtime files (~/.local/share/nvim/site) and checking in your config for any references to old cmd or deprecated plugins.
did an rm -rf ~/.local/share/nvim/site but log has same errors after deleting it and trying to open a cpp file.
references to old cmd
not sure what this is referring to but i did not see anything relating to “cmd” or something like it being used around my lsp stuff. the rest of the init.vim had autocmd stuff that didn’t look lsp or cpp specific.
well removed everything and reinstalled neovim from master.
good news is i no longer get that error where it tries to look in an old server location, however it can no longer find clangd. i installed clangd via williamboman/nvim-lsp-installer (:LspInstallInfo then press i on clangd in the list of servers) so ~/.local/share/nvim/lsp_servers/clangd exists.
set rtp? looks the same.
which clangd returns nothing. it’s unclear from the nvim-lsp-installer readme if you are supposed to setup a clangd alias or something in bash pointing to its install location. LspInfo does mention another client “cpp” so not sure what that is.
I know i did a similar ‘update-alternatives’ thing for my old sudo apt install clang-12 installs which were version 12. wondering if that’s playing a role.
I removed all my system clang stuff and was trying to get the lsp to find the one installed via the lsp installer plugin. still not sure why its looking in lspinstall folder.
I got my nvim stuff set up on Windows and I managed to get good lsp functionality.
One thing i did not mention about all this is that the repo resides on mnt/c side (so i can run/debug with msvc) while my nvim is on the linux side. i have used wsl2 to edit projects that reside on the Windows side without issue in the past (you have to use the linux side cmake to generate the compile_commands.json) but maybe there’s something about this project where it starts to choke on something.
My understanding of lsps is very poor so to me it seems like it should be no big deal, follow some paths in compile_commands and get some symbols. maybe someone with a better understanding is looking at this and thinking wtaf. My windows workflow ended up being this way since nvim on windows (both gui and terminal) in the past had been totally unusable for me, but it looks like that is no longer the case.
having gone through this exercise i get the feeling that magnitude of “off label use” with a linux-nvim-to-edit-windows-project might be much more than i thought, and not even worth mentioning on the forum? sry for wasting your time if that’s the case.
anyway for clangd on linux, lsp_server vs system gets the same results. they both will have the old lspinstaller path in the log file (its still unclear to me if that’s the root cause of some basic lsp stuff not working, like goto def of pod).
Did you clear the lspinstaller/resolve the path/wipe the compile commands.json linux side?
Can you look in compile_commands.json for references to the lspinstaller managed clangd’s headers?
, and not even worth mentioning on the forum? sry for wasting your time if that’s the case.
It’s fine, it’s just important to make these things known.
anyway for clangd on linux, lsp_server vs system gets the same results. they both will have the old lspinstaller path in the log file (its still unclear to me if that’s the root cause of some basic lsp stuff not working, like goto def of pod).
This is a message from clangd that indiciates its looking for headers, which IMO implies these are added to the compile_commands.json somehow
This is why I strongly recommend against using an lsp-installer plugin and just managing your servers manually via your system package manager hah.
fwiw there were no “lspinstaller” strings in the compile_commands when it was getting those strings in the log. there was a .cache folder in the root of the repo that may or may not have been playing a role. clangd puts it there.
not sure what i did but im using clang12 system stuff again and i no longer get those lspinstaller strings in the log.
the indexing percentage goes up to 100 but there a bunch of “Failed to compile” messages on all the project files.
I thought it might be not having visibility to some windows includes so i tried adding those to $PATH but still get “Failed to compile” messages.