Code completion using LSP and clangd

[killerbot]

today I tried to activate it on my linux box, I first disabled first the regular code completion plug-in, shutdown CB, started CB, then enabled the clangd based plug-in, which suggest me again to close and restart CB, so I did that.
When CB starts up again, it gives me an informational error message, to set the path of the clangd executable but the moment I open up settings-> Editor CB crashes, and I am never able to set it.
Below a snippet from the crash stack:

  <stack>
    <frame level="0" function="CodeBlocksApp::OnFatalException()" offset="00000000"/>
    <frame level="1"/>
    <frame level="2"/>
    <frame level="3" function="wxSpinCtrlGTKBase::DoSetValue(double)" offset="00000000"/>
    <frame level="4" function="CCOptionsDlg::CCOptionsDlg(wxWindow*, ParseManager*, ClgdCompletion*, DocumentationHelper*)" offset="00000ba0"/>
    <frame level="5" function="ClgdCompletion::GetConfigurationPanel(wxWindow*)" offset="0000004b"/>
    <frame level="6" function="PluginManager::GetConfigurationPanels(int, wxWindow*, ConfigurationPanelsArray&amp;, cbConfigurationPanelColoursInterface*)" offset="00000165"/>
    <frame level="7" function="EditorConfigurationDlg::AddPluginPanels()" offset="00000000"/>
    <frame level="8" function="EditorConfigurationDlg::EditorConfigurationDlg(wxWindow*)" offset="00000000"/>
    <frame level="9" function="MainFrame::OnSettingsEditor(wxCommandEvent&amp;)" offset="00000000"/>
    <frame level="10" function="wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&amp;, wxEvtHandler*, wxEvent&amp;)" offset="0000006e"/>
    <frame level="11" function="wxEventHashTable::HandleEvent(wxEvent&amp;, wxEvtHandler*)" offset="00000073"/>
    <frame level="12" function="wxEvtHandler::TryHereOnly(wxEvent&amp;)" offset="0000004b"/>
    <frame level="13" function="wxEvtHandler::DoTryChain(wxEvent&amp;)" offset="00000043"/>
    <frame level="14" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000039"/>
    <frame level="15" function="wxWindowBase::TryAfter(wxEvent&amp;)" offset="00000052"/>
    <frame level="16" function="wxEvtHandler::SafelyProcessEvent(wxEvent&amp;)" offset="00000007"/>
    <frame level="17" function="wxMenuBase::SendEvent(int, int)" offset="0000009b"/>

[killerbot]

from the conf file

   <clangd_client>
      <PARSER_DEFAULTS_CHANGED bool="1" />
      <PARSER_FOLLOW_LOCAL_INCLUDES bool="1" />
      <PARSER_FOLLOW_GLOBAL_INCLUDES bool="1" />
      <WANT_PREPROCESSOR bool="1" />
      <PARSE_COMPLEX_MACROS bool="1" />
      <PLATFORM_CHECK bool="1" />
      <SPLITTER_POS int="250" />
   </clangd_client>


maybe I can manually add it here, what's the directive ?


EDIT: added
      <LLVM_MASTERPATH>
         <str>
            <![CDATA[/opt/llvm/bin/clangd]]>
         </str>
      </LLVM_MASTERPATH>


still crashes as hard

[Pecan]

@Killerbot

Tomorrow (dec 13) I'll run through your described steps and see if I can catch the crash. Looks like it might be in a config option I've not tested on linux.

[Pecan]

today I tried to activate it on my linux box, I first disabled first the regular code completion plug-in, shutdown CB, started CB, then enabled the clangd based plug-in, which suggest me again to close and restart CB, so I did that.
When CB starts up again, it gives me an informational error message, to set the path of the clangd executable but the moment I open up settings-> Editor CB crashes, and I am never able to set it.

... edited ...

@Killerbot

I've tried for many hours to re-create this error on both Linux Mint20.2 and WSL2 with no success.

I've uploaded a video of a Mint20.2 run at
https://www.dropbox.com/s/d6lhsxbzi64x9cr/ClangdClientVideo_221214.zip?dl=0
The zip file contains a .wmv which played on both my windows and Mint systems, but not on my WSL2 (WSL2 requires a whole bunch of additional install fooey).

Note: I used a virgin CB profile (.conf) to do testing, but I only have gtk3 (64bit) to test with. So I couldn't try testing with gtk2.

We might get closer to the error if you would do the following.
Compile clangd_client with -g set to get debug symbols.

Run CB in the debugger and perform the steps you performed to get the error. Then lets have a look at the backtrace.

If debugging is not an option, just copy the -g compiled devel32_64 version of clangd_client dll into your output32_64 plugin folder and perform the steps that caused the error.
You should then get a .rpt file in the output32_64 folder which will have the statement that caused the crash.

Try doing all the above with a virgin personality, eg "run.sh -p virginConf"
If it runs with the virgin conf, we'll know it has something to do with the .conf contents.

In all your spare time :>) you might have a look at:
https://wiki.codeblocks.org/index.php/CB_Clangd_Client
to see if anything was missed there (but I doubt it has anything to do with this crash).

Thanks

[Pecan]

today I tried to activate it on my linux box, I first disabled first the regular code completion plug-in, shutdown CB, started CB, then enabled the clangd based plug-in, which suggest me again to close and restart CB, so I did that.
When CB starts up again, it gives me an informational error message, to set the path of the clangd executable but the moment I open up settings-> Editor CB crashes, and I am never able to set it.
Below a snippet from the crash stack:
... snipped ...

Finally managed to catch the crash.
Fixed in Head rev 13120.

Thanks

[ollydbg]

today I tried to activate it on my linux box, I first disabled first the regular code completion plug-in, shutdown CB, started CB, then enabled the clangd based plug-in, which suggest me again to close and restart CB, so I did that.
When CB starts up again, it gives me an informational error message, to set the path of the clangd executable but the moment I open up settings-> Editor CB crashes, and I am never able to set it.
Below a snippet from the crash stack:
... snipped ...

Finally managed to catch the crash.
Fixed in Head rev 13120.

Thanks

Good work, I once see your changes in rev 13120.

Code

 src/plugins/contrib/clangd_client/src/codecompletion/codecompletion.cpp | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/plugins/contrib/clangd_client/src/codecompletion/codecompletion.cpp b/src/plugins/contrib/clangd_client/src/codecompletion/codecompletion.cpp
index cd42a081..22d40c47 100644
--- a/src/plugins/contrib/clangd_client/src/codecompletion/codecompletion.cpp
+++ b/src/plugins/contrib/clangd_client/src/codecompletion/codecompletion.cpp
@@ -2895,7 +2895,6 @@ void ClgdCompletion::OnAppStartupDone(CodeBlocksEvent& event)
             msg << _("\n\nDo you want to use the detected clangd?");
 
             wxWindow* pTopWindow = GetTopWxWindow();
-            cbMessageBox(msg, _("ERROR: Clangd client"), wxOK, pTopWindow);
             if (cbMessageBox(msg, _("ERROR: Clangd client"), wxICON_QUESTION | wxYES_NO, pTopWindow) == wxID_YES)
             {
                 cfg->Write(_T("/LLVM_MasterPath"), fnClangdPath.GetFullPath());

Maybe, you can add a comment on the pTopWindow, because the next line, there is still a cbMessageBox() function call.
But that function does allow passing a nullptr pTopWindow pointer as the last argument.

[killerbot]

gone test the fix soon. Note on the other hand since manually adding this path, I do think the plug-in is doing stuff, since i get information as tooltips.

[killerbot]

still happens

    <frame level="0" function="CodeBlocksApp::OnFatalException()" offset="00000000"/>
    <frame level="1"/>
    <frame level="2"/>
    <frame level="3" function="wxSpinCtrlGTKBase::DoSetValue(double)" offset="00000000"/>
    <frame level="4" function="CCOptionsDlg::CCOptionsDlg(wxWindow*, ParseManager*, ClgdCompletion*, DocumentationHelper*)" offset="00000ba0"/>
    <frame level="5" function="ClgdCompletion::GetConfigurationPanel(wxWindow*)" offset="0000004b"/>
    <frame level="6" function="PluginManager::GetConfigurationPanels(int, wxWindow*, ConfigurationPanelsArray&amp;, cbConfigurationPanelColoursInterface*)" offset="00000165"/>
    <frame level="7" function="EditorConfigurationDlg::AddPluginPanels()" offset="00000000"/>
    <frame level="8" function="EditorConfigurationDlg::EditorConfigurationDlg(wxWindow*)" offset="00000000"/>
    <frame level="9" function="MainFrame::OnSettingsEditor(wxCommandEvent&amp;)" offset="00000000"/>
    <frame level="10" function="wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&amp;, wxEvtHandler*, wxEvent&amp;)" offset="0000006e"/>
    <frame level="11" function="wxEventHashTable::HandleEvent(wxEvent&amp;, wxEvtHandler*)" offset="00000073"/>
 

[killerbot]

other questions, what should functions calling 'foo' do, it gives me nothing and opens u[ the tab at the bottom of cscope ?

[Pecan]

other questions, what should functions calling 'foo' do, it gives me nothing and opens u[ the tab at the bottom of cscope ?

Geez, I have no idea what you're referring to.


What do you mean by "function calling "foo" ?
What do you mean by "bottom of cscope" ?

clangd_client has nothing to do with whatever that is.

Could you show us a list of the plugins you're running? I'll try to configure like your plugin setup.
I'm leaning toward believing we have a plugin conflict here.

[Pecan]

still happens

    <frame level="0" function="CodeBlocksApp::OnFatalException()" offset="00000000"/>
    <frame level="1"/>
    <frame level="2"/>
    <frame level="3" function="wxSpinCtrlGTKBase::DoSetValue(double)" offset="00000000"/>
    <frame level="4" function="CCOptionsDlg::CCOptionsDlg(wxWindow*, ParseManager*, ClgdCompletion*, DocumentationHelper*)" offset="00000ba0"/>
    <frame level="5" function="ClgdCompletion::GetConfigurationPanel(wxWindow*)" offset="0000004b"/>
    <frame level="6"
... snipped ...

Hail Mary pass rev 13122.
That spinCtrl is the first item in the clangd_client .xrc files that changed from the CC xrc files. Is that a clue or what?

I've now change all the class="wxPanel" name=<> names to be different for those in the CC xrc files which I shamelessly copied from CodeCompletion plugin. I think doing that just bit me in the butt.

I'm guessing that CB did NOT load the clangd_client xrc files
 for Killerbots version of Linux because the main wxPanel had the same name as the CC main wxPanel.

I can hear it in my head. CB says: "Oh hell. I don't have to load that crap; the panel name's the same as the one I loaded for CC. Let 'em  eat that."

Give it another try Killerbot. I'm holding my fingers crossed.
Just for my education, what version of Linux are you using?
Is it the same one you were using in 2005 ? :>)

Thanks 

[killerbot]

it is fixed :-)

my OS :
cat /etc/os-release
NAME="openSUSE Leap"
VERSION="15.4"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.4"
PRETTY_NAME="openSUSE Leap 15.4"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.4"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Leap"
LOGO="distributor-logo-Leap"

[killerbot]

on the other topic :

When you right click on a function/class method (say it is called 'foo'), you can select :  Find functions calling 'foo'

I would assume this comes also from the CC plug-in ?
This opens up the tab of the plug-in cscope (or maybe this is from cscope ??), and I jumped to conclusion the (clangd based) CC plug-in does that ?

[ollydbg]

on the other topic :

When you right click on a function/class method (say it is called 'foo'), you can select :  Find functions calling 'foo'

I would assume this comes also from the CC plug-in ?
This opens up the tab of the plug-in cscope (or maybe this is from cscope ??), and I jumped to conclusion the (clangd based) CC plug-in does that ?

The "Find functions calling 'foo'" is not from the clangd_client plugin. I guess it is from the cscope plugin.

[Pecan]

I have some situation that there are many information messages showing: LSP: File not yet parsed.

The step is:

1, double click on a file in the source navigation tree, and a new editor is opened.
2, mouse hover on some symbols in the editor.
3, the information massage happens.

Sometimes, I got this information messages showing many times, I think there is a logic error.

... quote modified by pecan ...

Finally !! Caught and fixed in Head rev 13134
It seems clangd server started (at some point) sending an empty textDocument/publishDiagnostics
response (with a missing "version" entry) to a didClose() request, which really confused clangd_client.

Thanks ollydbg :>)