Code completion using LSP and clangd

[stahta01]

Oh yes, as sodev said, I just disabled wxUSE_UNSAFE_WXSTRING_CONV. Those STL containers related options have been modified, too, but I don't think they really influence the conversion from wxString to std::string.

Since, IIRC, using STL means wxString is stored as std::string I would say you are technically right but, if the other person is using an STL built wxWidgets and you are not then you could have that as the cause of your problem!

Tim S.

[Pecan]

Hi Pecan,

compile_commands.json is read and parsed every time a file is opened. This uses a lot of CPU, especially during the initial parsing of all files, where
 compile_commands.json is read and parsed as many times as the number of files in the project. Attached patch does some optimisation for this.
1. Save the parsed compile_commands.json until the first batch parsing is completed, cleared after that.
2. After initial batch processing, all the filesnames are stored in a vector, and only if the filename is not present in this vector, compile commands is parsed. This helps to avoid parsing of the compile_commands.json after editing and saving of the file.

Thanks, Christo

Here some results from this christo patch.
The first millisecond measure following the filename is the parse time prior to the patch; the second is after applying the patch. There's a significant savings there. And it has a visible effect. It even feels faster.

Looks like I'll be applying the patch.
Thanks Christo.

Code

parser_base.cpp (1601 ms) (1264 ms)
codecompletion.cpp (2281 ms) (1776 ms)
LSP_tokenizer.cpp (1806 ms) (1235 ms)
parser.cpp (2462 ms) (1455 ms)
LSP_symbolsparser.cpp (2322 ms) (1706 ms)
coderefactoring.cpp (1744 ms) (1277 ms)
parsemanager.cpp (2274 ms) (1601 ms)
classbrowser.cpp (1723 ms) (1305 ms)
lspdiagresultslog.cpp (1253 ms) (524 ms)
ccoptionsdlg.cpp (1975 ms) (1554 ms)
ClangLocator.cpp (1295 ms) (1125 ms)
client.cpp (2417 ms) (1764 ms)
searchtree.cpp (596 ms) (329 ms)
cctreectrl.cpp (1983 ms) (1218 ms)
expression.cpp (2114 ms) (1238 ms)
token.cpp (1005 ms) (444 ms)
profiletimer.cpp (1983 ms) (251 ms)
ccdebuginfo.cpp (3174 ms) (1227 ms)
tokentree.cpp (2094 ms) (347 ms)
ccoptionsprjdlg.cpp (2878 ms) (1147 ms)
parsemanager_base.cpp (2345 ms) (410 ms)
selectincludefile.cpp (1791 ms) (395 ms)
doxygen_parser.cpp (3337 ms) (1299 ms)
StringUtils.cpp (491 ms) (346 ms)
gotofunctiondlg.cpp (1834 ms) (964 ms)
processreaderthread.cpp (1546 ms) (855 ms)
insertclassmethoddlg.cpp (2344 ms) (1155 ms)
procutils.cpp (1107 ms) (1078 ms)
winprocess_impl.cpp (1186 ms) (1076 ms)
winprocess.cpp (872 ms) (822 ms)
fileutils.cpp (1167 ms) (1219 ms)
asyncprocess.cpp (1755 ms) (1281 ms)

[eckard_klotz]

Hello Developers.

In his  Reply #88 on: February 11, 2022, 03:26:20 am ollydbg mentioned

If you are using the gcc from msys2, I mean the compilers in the folder "msys64\mingw64\bin", you should use "mingw-w64-x86_64-clang-tools-extra", which means the clangd.exe is under the folder "msys64\mingw64\bin" (the same folder in your gcc.exe).


If you are using the clang tool chain, I mean you use the compiler from the folder "msys64\clang64\bin", you should use "mingw-w64-clang-x86_64-clang-tools-extra".


I found that I just make a big mistake in one of my PC, that is I use the gcc toolchain from "msys64\mingw64\bin", but I use the clangd.exe from "msys64\clang64\bin", the result is I got a lot of LSP diagnostics messages about the errors.     Luckily I found the reason, and fix this issue. Hope this will help other guys. 

I faced the same issue. But I'm using the build-suite under in the folder "msys64\ucrt64\bin" and thus, I had to install package mingw-w64-ucrt-x86_64-clang-tools-extra for adding the clangd tool to my compiler-suite.

Maybe it is a good idea to add this in your wiki-page https://wiki.codeblocks.org/index.php/CB_Clangd_Client in the chapter Windows: Compiler Clangd/LLVM Package Installer


Best regards,
                   Eckard Klotz.

[ollydbg]

Hello Developers.

In his  Reply #88 on: February 11, 2022, 03:26:20 am ollydbg mentioned

If you are using the gcc from msys2, I mean the compilers in the folder "msys64\mingw64\bin", you should use "mingw-w64-x86_64-clang-tools-extra", which means the clangd.exe is under the folder "msys64\mingw64\bin" (the same folder in your gcc.exe).


If you are using the clang tool chain, I mean you use the compiler from the folder "msys64\clang64\bin", you should use "mingw-w64-clang-x86_64-clang-tools-extra".


I found that I just make a big mistake in one of my PC, that is I use the gcc toolchain from "msys64\mingw64\bin", but I use the clangd.exe from "msys64\clang64\bin", the result is I got a lot of LSP diagnostics messages about the errors.     Luckily I found the reason, and fix this issue. Hope this will help other guys. 

I faced the same issue. But I'm using the build-suite under in the folder "msys64\ucrt64\bin" and thus, I had to install package mingw-w64-ucrt-x86_64-clang-tools-extra for adding the clangd tool to my compiler-suite.

Maybe it is a good idea to add this in your wiki-page https://wiki.codeblocks.org/index.php/CB_Clangd_Client in the chapter Windows: Compiler Clangd/LLVM Package Installer


Best regards,
                   Eckard Klotz.

Hi, I think you can edit the wiki by yourself if you have a codeblocks forum account.

Can you try that? Thanks.

[eckard_klotz]

Hello Ollydbg.

Hi, I think you can edit the wiki by yourself if you have a codeblocks forum account.

Can you try that? Thanks.

OK, I tried and it was possible for me.

However, since I changed a document initially setup by somebody else, I would never do such a change without discussing it before.
Furthermore, it is important for me that somebody takes a look to it and if possible tries out if my extension describes really the correct procedure.

So it would be nice if somebody else will test it and will come back a comment if it works or not.

Best regards,
                     Eckard Klotz.

[ollydbg]

Hello Ollydbg.

Hi, I think you can edit the wiki by yourself if you have a codeblocks forum account.

Can you try that? Thanks.

OK, I tried and it was possible for me.

However, since I changed a document initially setup by somebody else, I would never do such a change without discussing it before.
Furthermore, it is important for me that somebody takes a look to it and if possible tries out if my extension describes really the correct procedure.

So it would be nice if somebody else will test it and will come back a comment if it works or not.

Best regards,
                     Eckard Klotz.

I understand your concern, and a wiki page is a shared resource, and I'm OK if you add any contribution to that page, especially this section:

7 Windows: Compiler Clangd/LLVM Package Installer

Thanks.