Code completion using LSP and clangd

[Pecan]

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.

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

Depends on what you mean by a local network.
Clangd_client and Clangd LSP server are all in the same machine communicating with pipes.

I'm not interested in arguments about clang use.
Clangd uses the parser, not the compiler.
CodeBlocks needs a modern parser for C++11 and beyond.
You don't have to use it.

[omlk]

Now it will be necessary to monitor what and how clang transmits over the network 
Wireshark now officially support msys2 to compile in Windows https://www.wireshark.org/news/20231115b.html

[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.

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)?

ollydbg will have to answer your question about COW strings.
It applies to legacy CodeCompletion but not so much to Clangd_Cllient.

@omlk

The COW strings issue. If I member correctly, recent GCC's std::string and wxString do not use the COW(copy on write). So, I think this issue is gone. Because the COW has many issue on multiple thread environment.

About the old legecy CodeCompletion plugin, the parser in this plugin has all hand written. But the modern C++'s grammar is very complex to parse, the parser failed to parse the source files if those files have many advanced C++ code.

Clangd is a compiler level parser, so it parse the source file correctly.

[omlk]

@ollydbg
Thanks for the answer. Then, if you know where to find information that will help improve code completion to a modern level, please let me know. Previously, someone wrote a code completion, but now - no one is capable of it?
The problem here is not to write the code, but to understand how it works, you can say the algorithm of actions.

[blauzahn]

I second the remark by @ollydbg. Modern C++ has gotten extremely complex to parse. Even before C++11 it was complex. Recent standards like C++20 have added a ton of additional complexity and are continuing to do so.

Have you ever met a C++-compiler or -library programmer? It is a humbling experience.

It would be a lot more useful to help solving problems already reported in the bugtracker. Thank you for offering help.

[DigitalSpaceDotName]

@ myztmy

Here's my compile of your source.
What's the problem you're presenting?
Please be aware that you have to correct the errors presented by clangd (in the LSP messages log) before clangd can give you proper analysis of your code.

Hi Pecan,

the issue he wanted to mention is that entering char # as described in the screenshot will offer in popup menu the class member method what make no sense in this location. But maybe I'm missing some idea?

I reproduced this issue.

Btw. I am unable to have working pre-processor code completion with clangd plugin from the beginning.
I'm not sure if it is nightly build intent, that not complete pre-processor statements or it is bug. I'm under latest windows 11.

In any case I'm forced to use auto launch typing 1 letter due missing prediction for shorter names than auto-launch in the code.
This is not really issue, but it is only mention.

In all the case very good work guys.

[Pecan]

Hi Pecan,

the issue he wanted to mention is that entering char # as described in the screenshot will offer in popup menu the class member method what make no sense in this location. But maybe I'm missing some idea?

I reproduced this issue.

Btw. I am unable to have working pre-processor code completion with clangd plugin from the beginning.
I'm not sure if it is nightly build intent, that not complete pre-processor statements or it is bug. I'm under latest windows 11.

In any case I'm forced to use auto launch typing 1 letter due missing prediction for shorter names than auto-launch in the code.
This is not really issue, but it is only mention.

In all the case very good work guys.
... quote snipped by pecan ....

Fixed head rev 13422.
Thanks for reporting and the clarification.

You also no longer have to set the launch at 1 char.

Note that clangd does not offer a list of prior defined names or macros. It offers only a pattern of preprocessor statements.

[DigitalSpaceDotName]

Great job.

It works for preprocesor as expected and maybe more better than expected.


Thank you.

[ollydbg]

I noticed that this plugin(the latest revision) can have the #include <xxxx> code completion for the header files, this is a really nice feature.

[Pecan]

Clangd Code Action (aka "fix available") is enabled from Head rev 13484.

Right-click any LSP log message containing "fix available" and select "Apply fix available" from the context menu.

[ollydbg]

Clangd Code Action (aka "fix available") is enabled from Head rev 13484.

Right-click any LSP log message containing "fix available" and select "Apply fix available" from the context menu.

This is a really nice feature! Good work!!! I will try it soon.

[gd_on]

I have problems with this new svn 13484 version, even after a full C::B rebuild. I use wxWidgets 3.2.4 for C::B on a Windows 11 64 bits.
C::B compiles normally. executable launches normally too, but when I try to open a project, I obtain an unhandled exception. I can try to continue, but C::B does not work as it should.
I have a rpt file which indicates problems within wxsmithlib.dll, but strangely no references to clangd plugin, but it's certainly this plugin which causes the problem. I had no such problem with my previous svn 13482.
I'm on windows 11 fully updated. I use gcc, clangd,... form msys2 installation, fully updated too.
If I disable clangd plugin and use standard codecompletion, it works correctly.

May be, it's something wrong on my side, but until now, I have not found the problem.

gd_on

[Pecan]

@gd_on
Please copy the newly built clangd_client.dll from the devel folder to the output folder (since the devel version has debugger info) and try again.

The exception should be caught if you'll respond with "stop" to the exception notice and the .rpt file should have a backtrace.

Alternatively, you could run coldeblocks in the debugger and repond "stop" to the exception and the debugger will stop on the exception line.

Make sure that your debugger options are set to "catch c++ exceptions" and that you compiled all of codeblocks with the -g compiler option (Settings/Globals cb_release_type).

Thanks.

[gd_on]

Very strange ... This morning, after a new full rebuild, it works, no unhandled exception ! I cross my fingers.

gd_on

PS : my problem was apparently that I use my own version of cbp to build clang plugin. Normally, it is compatible with Pecan's one, except that I have no option -g and use -std=gnu++20 instead of -std=gnu++11.
If I restore those two options, as in Pecan's .cbp, it's OK.

[Pecan]

Very strange ... This morning, after a new full rebuild, it works, no unhandled exception ! I cross my fingers.

gd_on

PS : my problem was apparently that I use my own version of cbp to build clang plugin. Normally, it is compatible with Pecan's one, except that I have no option -g and use -std=gnu++20 instead of -std=gnu++11.
If I restore those two options, as in Pecan's .cbp, it's OK.

@gd_on

That's interesting. Looks like I'd better do some testing with gnu++20.
Thanks for reporting that.

Please tell me the version of gcc and clangd you're using so I can exactly mirror your evnvironment.  Tell me also anything else you think I should mirror?