Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Code completion using LSP and clangd
Pecan:
--- Quote from: ollydbg on July 09, 2022, 06:55:37 am ---I'm building this plugin with the latest wx 3.2.0 release.
The source code I use is the latest rev: [r67]
It looks like I see "Requested token Not found" MessageBox when I use the mouse right context menu-> find declaration.
I switch back to an old rev [r66], which I build against wx 3.1.7, and I don't see this issue there.
Does any one notice the same issue?
Thanks.
EDIT:
I just build the revision 66 against wx 3.2.0, and it works OK.
So, my guess is some regression in this plugin's source code in revision 67.
--- End quote ---
That message box is still in rev 66 also. So some logic changed that is causing clangd to send back an empty response in rev 67.
Can you tell me how to re-create the situation with rev 67?
ollydbg:
--- Quote from: Pecan on July 10, 2022, 06:05:03 pm ---
That message box is still in rev 66 also. So some logic changed that is causing clangd to send back an empty response in rev 67.
Can you tell me how to re-create the situation with rev 67?
--- End quote ---
I'm using C::B for my own big project.
Let me create a minimal project for testing(reproduce this bug)
ollydbg:
I see one issue:
When I open the client or server log(which locates under the C:\Users\[myusername]\AppData\Local\Temp\)
I got to see something like:
--- Code: ---09:59:08.833 SystemPath: F:\code\msys2-64\mingw64\bin;F:\code\msys2-64\mingw64;..\usr\bin;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Windows\System32;C:\Windows;
--- End code ---
However, I see the string "..\usr\bin" is wrong here.
Because in the C::B Menu->Settings->Compiler->Tool Chain executable->Addtional Paths, I have one string
--- Code: ---$(TARGET_COMPILER_DIR)../usr/bin
--- End code ---
So, it looks like the TARGET_COMPILER_DIR is not replaced by the "F:\code\msys2-64\mingw64".[/code]
ollydbg:
--- Quote from: ollydbg on July 11, 2022, 07:44:47 am ---
--- Quote from: Pecan on July 10, 2022, 06:05:03 pm ---
That message box is still in rev 66 also. So some logic changed that is causing clangd to send back an empty response in rev 67.
Can you tell me how to re-create the situation with rev 67?
--- End quote ---
I'm using C::B for my own big project.
Let me create a minimal project for testing(reproduce this bug)
--- End quote ---
Here is my research on the "find declaration failure".
For some unknown reasons, the find declaration gives empty result, see the log below:
--- Code: ---11:30:17.039 <<< GoToDeclaration:
file:///F:/MyProject/JsonRead.cpp,line[41], char[30]
11:30:17.040 <<< Content-Length: 211
{"id":"textDocument/declaration","jsonrpc":"2.0","method":"textDocument/declaration","params":{"position":{"character":30,"line":41},"textDocument":{"uri":"file:///F:/MyProject/JsonRead.cpp"}}}
11:30:17.155 >>> readJson() len:61:
{"id":"textDocument/declaration","jsonrpc":"2.0","result":[]}
--- End code ---
While for another place, it works OK, see the log below:
--- Code: ---
11:30:30.454 <<< GoToDeclaration:
file:///F:/MyProject/ImagePanel.cpp,line[207], char[21]
11:30:30.455 <<< Content-Length: 214
{"id":"textDocument/declaration","jsonrpc":"2.0","method":"textDocument/declaration","params":{"position":{"character":21,"line":207},"textDocument":{"uri":"file:///F:/MyProject/ImagePanel.cpp"}}}
11:30:30.659 >>> readJson() len:199:
{"id":"textDocument/declaration","jsonrpc":"2.0","result":[{"range":{"end":{"character":14,"line":35},"start":{"character":6,"line":35}},"uri":"file:///F:/MyProject/ImagePanel.h"}]}
--- End code ---
So, it looks like the problem is in clangd side.
I will do more research on this issue, and try to make a minimal sample code.
Strange that clangd does not show the errors when parsing:
--- Code: ---LSP diagnostics: JsonRead.cpp|:|----Time: 11:30:08.905---- (0 diagnostics)|
--- End code ---
ollydbg:
I stripped down to a minimal code snippet: (you should save the code to UTF8 format)
--- Code: ---int abc;
int main()
{
abc = 3;
}
#include <string>
std::string Utf8ToGbk(const std::string& strUtf8);
std::string Utf8ToGbk(const std::string& strUtf8)
{
// 上面的函数
// return unicodeString.ToStdString(); // 默认使用当前操作系统的编码格式，Windows通常为GB2312
return strUtf8;
}
--- End code ---
You can see that if you right click on the "strUtf8", and find declaration gives empty result. The same as the "abc".
But if you remove the line:
--- Code: ---// 上面的函数
--- End code ---
Then, everything works expected.
Can you guys reproduce this bug?
Thanks.
BTW: I have some local patches to enable the the utf8 handling, but I'm not sure they are related.
--- Code: ----------------------- clangd_client/src/LSPclient/client.cpp --------------------
index 26ae994..fa1d7ca 100644
@@ -1162,7 +1162,7 @@ bool ProcessLanguageClient::DoValidateUTF8data(std::string& strdata)
if (not i18n) //if not internationalization show U(<codepoint>)
{
// With internationalization the wxUniChar gets an assert in wxString::Format
- wxUniChar uniChar(invChar);
+ wxUniChar uniChar((unsigned int)invChar);
msg += wxString::Format("position(%d), hex(%02hhX), U(%x), \'%s\'", invloc, (unsigned int)invChar, (int)uniChar.GetValue(), invStr );
}
else
--- End code ---
and
--- Code: ----------------------- clangd_client/src/LSPclient/client.cpp --------------------
index df36437..66bfad8 100644
@@ -2629,6 +2629,7 @@ void ProcessLanguageClient::LSP_DidChange(cbEditor* pEd)
}
didChangeEvent.text = edText;
+ didChangeEvent.text = edText.ToUTF8(); //Trying to find bad utf8 problem
std::vector<TextDocumentContentChangeEvent> tdcce{didChangeEvent};
DocumentUri docuri = DocumentUri(fileURI.c_str());
// **debugging**
--- End code ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version