Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Code completion using LSP and clangd

<< < (46/92) > >>

Pecan:
<Partial quote>

--- Quote from: ollydbg on October 15, 2022, 12:56:32 pm ---Hi, Pecan, In the latested r84 and with the change to using the std::string output of the both function writeClientLog() and writeServerLog().

I found an interesting thing that I got two different encoding output of the Chinese text in the comments.
One place is here, in the function: bool ProcessLanguageClient::WriteHdr(const std::string &in)
I see that the output of the content(usually the textDocument/didOpen message's content the client try to send to the LSP server) will be in GB2312 in my PC.
While, the content received from the server(usually the textDocument/hover message return from the LSP server) will be in UTF8 format.

I just exam the function body: bool ProcessLanguageClient::WriteHdr(), I see it still use the some kinds of std::string to wxString, and later some wxString to std::string, some conversion will use the default local encoding.

For example:

--- Code: ---limitedLogOut = wxString::Format("<<< Write():\n%s", wxString(in)).Mid(0,512) + "<...DATA SNIPED BY LOG WRITE()...>";

--- End code ---

The variable in to wxString will use wrong encoding.

So, what I think is that we should use std::string inside the WriteHdr().
[/code]

--- End quote ---

Fixed in rev 85. At least I think so. I can't produce an environment that lets me accurately use chinese characters.

When I try to paste copied chinese chars into the editor it automatically converts them to utf8.

Tell me if it actually fixes this.

Thanks for testing and for the fixes.

Pecan:

--- Quote from: MaxGaspa on October 15, 2022, 09:36:37 am ---
--- Quote from: Pecan on October 14, 2022, 09:45:18 pm ---
I've made a temporary fix (until the next Nightly) that circumvents the missing event.

Be careful though, the circumvention allows clangd to parse files while the "Run" command is active. You might want to right-click on the project name and "Pause parsing(toggle)" before running your program from the menu run command.

After the "Run" finishes, you can "Pause parsing(toggle)" again to continue parsing where it left off.


--- End quote ---

@pecan

At the moment I'm unable to replicate the bug, so the bug seems fixed.

Is there any inconvenience leaving the parser working while I'm running the application? I mean not considering the CPU usage?

Max

--- End quote ---

You can set the number of parsers you would like to run while compiling,running,debugging can be set at Settings/Editor/Clangd_client/"C/C++ parser"/Max number of threads while compiling.

But it really eats up the cpu. Set it to about 1/2 the number of processors/threads in your cpu.

Then sit back and feel it warm up the house and enjoy the aroma of melting plastic.

ollydbg:

--- Quote from: Pecan on October 16, 2022, 01:57:16 am ---<Partial quote>

--- Quote from: ollydbg on October 15, 2022, 12:56:32 pm ---Hi, Pecan, In the latested r84 and with the change to using the std::string output of the both function writeClientLog() and writeServerLog().

I found an interesting thing that I got two different encoding output of the Chinese text in the comments.
One place is here, in the function: bool ProcessLanguageClient::WriteHdr(const std::string &in)
I see that the output of the content(usually the textDocument/didOpen message's content the client try to send to the LSP server) will be in GB2312 in my PC.
While, the content received from the server(usually the textDocument/hover message return from the LSP server) will be in UTF8 format.

I just exam the function body: bool ProcessLanguageClient::WriteHdr(), I see it still use the some kinds of std::string to wxString, and later some wxString to std::string, some conversion will use the default local encoding.

For example:

--- Code: ---limitedLogOut = wxString::Format("<<< Write():\n%s", wxString(in)).Mid(0,512) + "<...DATA SNIPED BY LOG WRITE()...>";

--- End code ---

The variable in to wxString will use wrong encoding.

So, what I think is that we should use std::string inside the WriteHdr().
[/code]

--- End quote ---

Fixed in rev 85. At least I think so. I can't produce an environment that lets me accurately use chinese characters.

When I try to paste copied chinese chars into the editor it automatically converts them to utf8.

Tell me if it actually fixes this.

Thanks for testing and for the fixes.

--- End quote ---

Hi, Pecan, I just tested this rev 85, and I can confirm that the encoding issue is fixed. In the log file, both the textDocument/didOpen and textDocument/hover messages are showing the same UTF8 encoding now.

ollydbg:
Hi, Pecan, I try to debug clangd_client, but disable all the other plugins. So I have the patch here:

Re: How to exclude the other plugins when debugging

But when I have only two plugins to load, in the debug-plugin.conf file, I have such content:


--- Code: --- <plugins>
<TRY_TO_ACTIVATE>
<str>
<![CDATA[]]>
</str>
</TRY_TO_ACTIVATE>
<INSTALL_GLOBALLY bool="1" />
<INSTALL_CONFIRMATION bool="1" />
<BATCH_BUILD_PLUGINS>
<astr>
<s>
<![CDATA[compiler.dll]]>
</s>
<s>
<![CDATA[clangd_client.dll]]>
</s>
</astr>
</BATCH_BUILD_PLUGINS>
<CLANGD_CLIENT bool="1" />
</plugins>

--- End code ---

This means only those two dlls get loaded.

But when debugging, I see the debugee codeblocks will report that:


--- Code: ---[Window Title]
Clangd_client plugin

[Content]
The Clangd client plugin cannot run while the "Code completion" plugin is enabled.
The Clangd client plugin will now inactivate itself. :-(

If you wish to use the Clangd_client rather than the older CodeCompletion plugin,
navigate to Plugins->Manage plugins... and disable CodeCompletion, then enable Clangd_client.

Restart CodeBlocks after closing the "Manage plugins" dialog.

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
Only one (Clangd_Client or CodeCompletion) should be enabled.

[OK]

--- End code ---


In my plugin management dialog, I have only two plugins, so CodeCompletion plugin is not loaded. I'm not sure why in this case, clangd_client still report the codecompletion is enabled?

Thanks.


EDIT

It looks like the clangd_client has some logic to detect the codecompletion plugin, but the logic is not correct.

Now, I have a workaround, I have change the conf file to have this:


--- Code: --- <plugins>
<TRY_TO_ACTIVATE>
<str>
<![CDATA[]]>
</str>
</TRY_TO_ACTIVATE>
<INSTALL_GLOBALLY bool="1" />
<INSTALL_CONFIRMATION bool="1" />
<BATCH_BUILD_PLUGINS>
<astr>
<s>
<![CDATA[compiler.dll]]>
</s>
<s>
<![CDATA[clangd_client.dll]]>
</s>
<s>
<![CDATA[codecompletion.dll]]>
</s>
</astr>
</BATCH_BUILD_PLUGINS>
<CLANGD_CLIENT bool="1" />
<CODECOMPLETION bool="0" />
</plugins>
--- End code ---
Then, I can enable the clangd_client plugin correctly. (the codecompletion plugin should be loaded but disabled)

The situation is: if the codecompletion plugin never get loaded, I have no way to enable the clangd_client plugin.  :(

ollydbg:
I see another crash caught by GDB.


--- Code: ---From b54738b2d2d2eec2eb7185f14f7c0e1f7c75c68f Mon Sep 17 00:00:00 2001
From: asmwarrior <a@b.com>
Date: Fri, 28 Oct 2022 21:22:01 +0800
Subject: delete the instance first, and later remove it from the list

If first remove from the list, the iterator becomes invalid, remember the pointer before the iterator get destroyed

diff --git a/clangd_client/src/codecompletion/parsemanager.cpp b/clangd_client/src/codecompletion/parsemanager.cpp
index 1590f31..9101ddd 100644
--- a/clangd_client/src/codecompletion/parsemanager.cpp
+++ b/clangd_client/src/codecompletion/parsemanager.cpp
@@ -713,11 +713,12 @@ bool ParseManager::DeleteParser(cbProject* project)
 
         // The logic here is : firstly delete the parser instance, then see whether we need an
         // active parser switch (call SetParser())
-        m_ParserList.erase(parserList_it); //remove deleted parser from parser list
-        delete parserList_it->second;
+        ParserBase* delParser = parserList_it->second;
+        delete parserList_it->second;      // delete the instance first, then remove from the list
+        m_ParserList.erase(parserList_it); // remove deleted parser from parser list
 
         // if the active parser is deleted, set the active parser to nullptr
-        if (parserList_it->second == m_Parser)
+        if (delParser == m_Parser)
         {
             m_Parser = nullptr;
             SetParser(m_TempParser); // Also updates class browser; do not use SetParser(m_TempParser) //(ph 2022/06/6)-


--- End code ---

This will fix the crash.


EDIT:

I updated the patch, because I see the iterator get invalid, so we have to member the pointer address for later comparing.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version