Clangd support and clarification on CMake structure #2408
Comments
|
@amitrahman1026 thanks for this feedback. I need to do a research on this for a definite answer. My current understanding is that relative includes are automatically found relative to the source file by the compiler therefore there's no need to pass extra The previous version of CLion was using clangd as its code understanding backend, and it was able to find these headers somehow so that they were navigatable in the IDE. Could you say:
How does it manifest? How do you try to "jump further"? |
|
Thanks for the response @battlmonstr, I'd been fiddling around further with clangd, and I am still in the process of investigating but it may draw to a close soon because I generally have it working and have found a similar lead here! To respond to your questions,
-- LSP
{
"neovim/nvim-lspconfig",
cmd = { "LspInfo", "LspInstall", "LspStart" },
event = { "BufReadPre", "BufNewFile" },
dependencies = {
{ "hrsh7th/cmp-nvim-lsp" },
{ "williamboman/mason-lspconfig.nvim" },
},
config = function()
local lsp_zero = require("lsp-zero")
local lspconfig = require("lspconfig")
-- ...
-- Specific setup for clangd
lspconfig.clangd.setup({
cmd = { "/opt/homebrew/opt/llvm/bin/clangd" },
capabilities = require("cmp_nvim_lsp").default_capabilities(),
on_attach = lsp_attach,
})
Further in my investigations, I'd switched around between three different versions of clangd to see what was causing the issue. The initial was with a version of a clangd binary (unconfirmed what it was at the time) pulled by mason. I was unable to reproduce the backtrace failure however with mason's version of clangd. and I had overwritten the mason.logs. My first approaches to solve this lsp problem (for my setup because I understand there's probably not a real need for this for the majority of end users) was to throw more includes at it so put together some hacky recursive cmake just for compile_commands.json. Regardless that was a bandaid and not really a sustainable solution. Then I explored switching to native Finally, I came around to the probably source of my problem! llvm/llvm-project#109367. The bug report describes crashes due to certain Here, I have reproduced the (truncated) logs when using Fix-ish(?)Using the suggested method to remove the problematic check for clangd by adding the following to a I'll stay tuned to the fixes, and perhaps downgrade to llvm 18 in the meanwhile to retest as well. I think we can close this! This may have been due to misconfigurations/ lack of updated language servers on my part, rather than missing include flags! Appreciate you for taking some time to respond to this rather niche query :) |
|
@amitrahman1026 I'm glad that you've found a workaround. Our recommended IDEs for silkworm are CLion or Xcode, but it is good to ensure that VSCode and NeoVim also work. |
Hi! Firstly, thanks for your amazing work!
I am trying to get clangd to play nice, and hoping to get some support.
So I'm generated the
compile_commands.jsonfile for clangd to use as a compilation database. No furtherOne strange thing I notice is that the symbol definitions are incomplete. For e.g. when I'm working on the
silkworm/silkworm/sentry/sentry.hppfile.and I try to go to the definition of
Settingsfor instance in the snippetClangd only traces back up to the
#include "settings.hpp"directive and stops there, unable to jump further.This leads me to suspect that the lsp does not have enough information about the includes.
This led me to poke around in the generated
compile_commands.jsonto see the (truncated) node generated for the file and I notice-I/Users/amit/Cpp_Projects/silkwormis the only include that is relative.Now I understand that relative include directives like #include "settings.hpp" were used and this results in compilation working just fine, so I was hypothesizing that without the flag
-I/Users/amit/Cpp_Projects/silkworm/silkworm/{include dir}, clangd would not be able to get the full path of definition.Now I've tried a few permutations of where to include, below:
They do add the desired
-I/Users/amit/Cpp_Projects/silkworm/silkworm/sentryflag into thecompile_commands.jsonhowever its added to ALL of the nodes.Ultimately, I'm seeking some guidance on whether I'm missing something out and how I should approach this problem. While this is not critical maybe this has to do with the way the CMakeLists are handling include directories?
The text was updated successfully, but these errors were encountered: