Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Code completion using LSP and clangd
Pecan:
@ Christo: thanks.
@ olldbg
Sorry to keep you dancing like this but... 8>}
Would you reupdate to rev 13397.
While tracing the crash, I found other code that could cause re-entry into ClassBrowserBuildThread while it was busy.
This time, it's not a guess; I actually caught it and coded a fix that avoids the double entry.
Remember to copy Clangd_client dll from devel32_64 to output32_64 in case I'm full of (you know what); so that we can get line numbers on crashes.
TLDR:
Every time an editor is activated (happens every time the mouse moves into the text), it calls UpdateClassBrowser(). I should have known this, but my brain is old and rusting. And every 4th time a parser finishes a translation unit it invokes UpdateClassBrowserView(). Those two can happen at the same time. So I've moved busy checks just inside those functions to catch thread "busy" as soon as possible so one doesn't mod the TokenTree while the other is doing its business.
Clangd_client uses TryLocks(250 mil). If the lock fails, it was requeuing an idle time callback for the ClassBrowser update . I've remove these (for the time being) in case they were exacerbating the situation. Code now just skips the update.
I think I'll leave it that way until after the coming release.
There seems to be enough editor activating and background parsing to drive the update.
I haven't found any disadvantage so far.
Thanks !!
ollydbg:
Hi, Pecan, thanks. I appreciate your work on the clangd_client plugin.
I'm using the rev 13397 for about 6 hours, and I haven't see a crash here till now. :)
omlk:
--- Quote from: ollydbg on November 16, 2023, 10:09:29 am ---Hi, Pecan, thanks. I appreciate your work on the clangd_client plugin.
I'm using the rev 13397 for about 6 hours, and I haven't see a crash here till now. :)
--- End quote ---
I came across the post, and I wonder if you were able to implement what you wrote about?
https://forums.codeblocks.org/index.php?topic=17543.0
And I also wonder how much faster the clang_client works compared to the standard codecompletion (because my codecompletion in some cases does not see the classes, I changed the order of the included header files and disabled others, but there are still problems)?
Pecan:
--- Quote from: omlk on November 16, 2023, 02:15:14 pm ---
--- Quote from: ollydbg on November 16, 2023, 10:09:29 am ---Hi, Pecan, thanks. I appreciate your work on the clangd_client plugin.
I'm using the rev 13397 for about 6 hours, and I haven't see a crash here till now. :)
--- End quote ---
I came across the post, and I wonder if you were able to implement what you wrote about?
https://forums.codeblocks.org/index.php?topic=17543.0
And I also wonder how much faster the clang_client works compared to the standard codecompletion (because my codecompletion in some cases does not see the classes, I changed the order of the included header files and disabled others, but there are still problems)?
--- End quote ---
ollydbg will have to answer your question about COW strings.
It applies to legacy CodeCompletion but not so much to Clangd_Cllient.
Clangd_client only references the TokenTree with a mutex trylock. If it cannot obtain the lock it reschedules access to the TokenTree until it can obtain the lock.
Clangd_client works slightly slower than lagacy CC in that it uses the a Clangd LSP server to do all parsing of translation units (TU). It does no language parsing itself.
Its advantage is that it supports C++ versions as fast as the Clangd LLVM team can release Clangd support for that new C/C++ version.
The TU information is available to the user, for each activated (referenced) TU, about as fast as your cpu can run the Clangd parser. My Win10 system (an Intel i7/8 core) parses most TUs in 2 seconds or less. Giving Clangd more than 1 core makes for a speedy throughput since that allows Clangd to parse multiple TUs in parallel. I seldom have to wait for info.
For inistallation info see https://wiki.codeblocks.org/index.php/CB_Clangd_Client
omlk:
--- Quote from: Pecan on November 16, 2023, 07:20:44 pm ---The TU information is available to the user, for each activated (referenced) TU, about as fast as your cpu can run the Clangd parser. My Win10 system (an Intel i7/8 core) parses most TUs in 2 seconds or less. Giving Clangd more than 1 core makes for a speedy throughput since that allows Clangd to parse multiple TUs in parallel. I seldom have to wait for info.
--- End quote ---
clangd use local network? If that's the case, then clang can't run faster than the native way.
Google gave a result in the search, to what extent do you agree with what is described there about the negative facts of clang use.
https://www.eclipsecon.org/sites/default/files/slides/EclipseCon2018-cpp-lsp_0.pdf
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version