Code completion using LSP and clangd

[ollydbg]

Can you raise a ticket for this so I do not forget about it as it may not be as simple as changing the docs as the code may need some changes to ensure that end users with GCC and CLANG do not have issues like you found.

Done.

CB Clangd Client / Tickets / #37 use the compiler and clangd from the same folder(for msys2 the same package repositories)

[Pecan]

Fixed rev 44

I see some bugs here:

BUG1:

1, I have 5 cbp files in the same folder, and I also have a workspace file which contains the 5 cbp files.

2, I open the workskpace, and switch the active project between those 5 cbps

3, When I close the C::B or close the workspace, I got 4 error messages:

Code

19:17:44: File 'D:\code\plugin\wxModularApp\build\.cache\Clangd-cache.lock' couldn't be removed (error 2: 系统找不到指定的文件。)
19:17:45: File 'D:\code\plugin\wxModularApp\build\.cache\Clangd-cache.lock' couldn't be removed (error 2: 系统找不到指定的文件。)
19:17:45: File 'D:\code\plugin\wxModularApp\build\.cache\Clangd-cache.lock' couldn't be removed (error 2: 系统找不到指定的文件。)
19:17:45: File 'D:\code\plugin\wxModularApp\build\.cache\Clangd-cache.lock' couldn't be removed (error 2: 系统找不到指定的文件。)

The Chinese words means "System cannot find the file specified.".

So, I think that this plugin use the same .lock file name for all the cbp projects?



BUG2:

1, I have 5 cbp files in the same folder, and I also have a workspace file which contains the 5 cbp files.

2, I open the workskpace, and switch the active project between those 5 cbps.

3, Now, I use the git tool to update those 5 cbp files, and C::B asked that whether I need to reload the cbp files, I press "all".
Now, I see that my CPU usage is from the 25% CPU (which is the 1 thread in my clang_client setting) to 100%, and I see 4 clangd.exe running in the task manager window.
Each process of clangd eat about 25% of the cpu.

I guess that when 5 cbp files get reloaded in the same time, it will trigger several clangd.exe to run.

My testing project is:
asmwarrior/wxModularApp: Cross-Platform Modular Application (Main app + plugins) example for C++/wxWidgets

[Pecan]

Added your comment to the Install instructions
Rev 44. Thanks

Hi, guys, I think I found an issue when using clangd under msys2.

In the instruction:

CB Clangd Client / Code / [r41] /trunk/clangd_client/documentation-install/Windows-LLVM-ClangD-Install-Readme.txt

It said:

Code

MSYS2 Compiler - MinGW64
-------------------------
There are two main options to install the clangd.exe as follows:
    1) The first option in order to  minimise disk space is to install the Clang extra tools using one of the following packages:
        +------------------------------------------+------------------------+
        |               Package                    | Clangd executable      |
        +------------------------------------------+------------------------+
        | mingw-w64-clang-x86_64-clang-tools-extra | clang64/bin/clangd.exe |
        | mingw-w64-x86_64-clang-tools-extra       | mingw64/bin/clangd.exe |
        +------------------------------------------+------------------------+

       To intall the package do the following:
        a)  Open the msys2.exe bash shell 
        b) Run the following command:
               pacman -S <Package name in the table above>
    
 OR
    2) The second option is to intall the full Clang tool chain as follows:
        a)  Open the msys2.exe bash shell 
        b) Run the following command:
               pacman -S mingw-w64-clang-x86_64-toolchain

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. 

[Pecan]

Fixed rev 44.
Also added settings option to perform in the current manner.

There is another issue to show the LSP messages.

Suppose you have several cpp files in the cbp, when you first open the cbp, you get all the LSP diagnostics from all the cpp files.

But once you edit only one cpp file, and press "save" button, the whole "LSP message" will be cleaned, and only the recent saved cpp file's diagnostics will be shown.

So, I suggest if we can only update the updated files' message, but keep the old ones, thanks.

[Pecan]

Fixed in a rev previous to 44. Forgot to mention it.
Thanks for testing.

I see an annoying issue that the focus changes of the log message.

Here is the steps to reproduce:

1, I hit the "save" (or the "save all") toolbar botton
2, I hit the "build" toolbar botton
3, The building process starts, and the active log is switched to the build log
4, after for a while, the active log is switched to the LSP message.


In the step 4, it is a bit annoying. Can we stop the focus switch in the step 4?
Or we can only switch the LSP message if the compiler(build process) is not running.

Thanks.


EDIT:

I see such code snippet about the log switch(focus)

Code

        // If last request was anything but "textDocument/didSave", don't steal the log focus.
        if ( not popupActive ) switch(1)
        {
            default:
            // switch to LSP messages only when user used "save"
            if (not GetLSPClient()->GetSaveFileEventOccured()) break;
            wxWindow* pFocusedWin = wxWindow::FindFocus();
            if (not GetLSPClient()->LSP_GetLog()) break;

            CodeBlocksLogEvent evtSwitch(cbEVT_SWITCH_TO_LOG_WINDOW, GetLSPClient()->LSP_GetLog());
            CodeBlocksLogEvent evtShow(cbEVT_SHOW_LOG_MANAGER);
            Manager::Get()->ProcessEvent(evtSwitch);
            Manager::Get()->ProcessEvent(evtShow);
            if (pFocusedWin) pFocusedWin->SetFocus();
        }

I'm not sure why you combine the if and switch statement in the same line?

[ollydbg]

Hi, Pecan, thanks for your fix!

[gd_on]

r46 version : typos : two new strings start by "Warings", should be "Warnings".

[BlueHazzard]

I get a lot of this message boxes (see image)
and they block the workflow quite hard. Would it be possible to log this error messages only to console, and not show a message box?
As far as i can tell they do not interfere with the plugin, at least it seems to work.

(i use not the last version of the plugin. If this is fixed in the last version please ignore this, i will update the source soon)

[Pecan]

I get a lot of this message boxes (see image)
and they block the workflow quite hard. Would it be possible to log this error messages only to console, and not show a message box?
As far as i can tell they do not interfere with the plugin, at least it seems to work.

(i use not the last version of the plugin. If this is fixed in the last version please ignore this, i will update the source soon)

Those boxes were removed quite awhile back and written to the debug log instead.

You might want to download the nightly .dll and .zip, or update your clangd_client source.

Thanks for testing.

[ollydbg]

Is it possible to enable macro expansion for the llvm master path?

I mean this code:

Code

    ConfigManager* cfg = Manager::Get()->GetConfigManager(_T("clangd_client"));
    wxString cfgClangdMasterPath = cfg->Read("/LLVM_MasterPath", wxString());

For example, we can enter such string in the clangd_client setting dialog.

Code

$(TARGET_COMPILER_DIR)bin\clangd.exe

BTW: I use the string:

Code

$(TARGET_COMPILER_DIR)bin\gdb.exe

under the GDB plugin setting.

[gd_on]

I try to use clangd plugin. I use Msys2 and the compiler installed in mingw64/bin, so following your recommandations I have installed with pacman mingw-w64-x86_64-clang-tools-extra.
clangd is installed in mingw64/bin normally. After the first installation my clang64 folder contains only empty folders (\bin, ...). I don't use clang compiler, so that's normal. Like that, clangd plugin works as it should.
Nevertheless, after some time and a few pacman updates, I see several warnings during the update process, and clang64 folders are progressively filled with different files. May be the pacman update process is not well adapted to the installation of clangd inside mingw64 folders ! Dependencies may be ? And all those new files are probably not necessary for clangd client plugin.
My question is : what is striclly necessary for clangd client usage : clangd.exe + a few dlls (used by clangd.exe or may be a static version of clangd.exe), sure, but is there anything else, other dll, other executables ? could we remove the update process to avoid unnecessary filling of clang64 folder ?

[ollydbg]

Nevertheless, after some time and a few pacman updates, I see several warnings during the update process, and clang64 folders are progressively filled with different files. May be the pacman update process is not well adapted to the installation of clangd inside mingw64 folders ! Dependencies may be ? And all those new files are probably not necessary for clangd client plugin.

I have run the pacman updates today, and I didn't see such issue. I have clang64 folder, and I see there are some sub folders in this folder, but all are empty.

My question is : what is striclly necessary for clangd client usage : clangd.exe + a few dlls (used by clangd.exe or may be a static version of clangd.exe), sure, but is there anything else, other dll, other executables ? could we remove the update process to avoid unnecessary filling of clang64 folder ?

I guess your msys2 has some issue. You can try to remove the files/packages in clang64 folder, I have did that before, use such command:

Code

pacman -R $(pacman -Qsq 'mingw-w64-clang-x86_64*')

[gd_on]

I have already tried to uninstall all my msys2, using the pacman -R option and even delete everything manually (C:\msys64), reinstalling msys2 (in C:\msys64), reinstalling C:\msys64\mingw64 and only clang64 extra tools in mingw64. Everything happens correctly and clangd plugin works, but after a while and several upddates with pacman during a few weeks, my C:\msys64\clang64 folder is progressively filled with different things as python, sqlite, p11-kit, ... etc. clangd.exe is still in C:\msys64\mingw64\bin.
So, what could be wrong, I don't know.

PS:
I have tried your command line. Though I was sure everything was suppressed from a previous standard clang try, many packages have been found. Obviously, there was things in the cache that was still there, but not installed as far as I understand. May be that was my problem. Wait and see in 2 or 3 weeks !

[Pecan]

@Ollydbg

Is it possible to enable macro expansion for the llvm master path?

Code

$(TARGET_COMPILER_DIR)bin\clangd.exe

Yes, I'll do that. Good suggestion.

[ollydbg]

I have an issue to use the "find declaration" tool.
Find the declaration of a symbol in a header file, but the header file is not belong to the cbp project.


I have a project, say, it has a file named a.cpp. In this file, I have some definition like

Code

TypeA a;

And the TypeA is defined in a header file (e.g. TypeA.h), which is not belong to the cbp project, say, it could be in a include search path.

Now, when I use the "find declaration of TypeA", I see LSP can correctly jump to the TypeA.h.

Now, say the TypeA is actually a typedef, such as:

Code

typedef TypeB TypeA;

Now, when I right click on the TypeB symbol, and "find declaration of TypeB", I see the clangd_client plugin will jump a messagebox, it said:

[Window Title]
LSP OnGotoDeclaration

[Content]
The editor's file does not have an associated project.
Perhaps add the file to a project ?

[OK]

This looks wrong, I mean if the a.cpp get parsed by clangd, it should understand where TypeB is declared. So, is this a bug? I think adding the TypeA.h to my cbp project is not the correct way to solve this issue.

Any ideas?

Thanks.