What is the purpose of this LSP plugin? Just provide faster error messages?Using the LSP, I think at least code completion list will be more precise than the native CC.
In my experience implementing a CC plugin with LSP doesn't work well (don't remember the details).
Shipping clangd is a windows thing. I don't think we should do it. Just detect the LLVM installation and use it. Or prompt the user to install it.
What is the purpose of this LSP plugin? Just provide faster error messages?
In my experience implementing a CC plugin with LSP doesn't work well (don't remember the details).
...<snip>...
If I remember correctly, there is an option in CodeLite IDE, which can let user select which clangd.dll it will use.
Do you have a code repo which others can build/test this plugin?
...<snip>...
Clangd supports all the LSP calls plus it's own extensions. So far, I've implemented all CB CC's features via LSP calls except the Symbols browser. Though that's possible to do.I know that, CC features required changes to the CCManager API last time I've tried to do it. At least if you want to provide good experience.
For the record the latest version of clang is 11.1. clang/llvm 12 is some night build. This would fail dramatically on linux if you base your development on this version at least until clang/llvm 12 is actually released in the summer.
I know that, CC features required changes to the CCManager API last time I've tried to do it. At least if you want to provide good experience.
I don't think implementing the diagnostics in another info pane tab is a good idea, but this requires another CCManager change which would allow in-editor-notifications.
Also I don't know how is using a mix of clang/gcc these days, but it was a problem in the past.
Also I'm not sure if it is a good idea to base your LSP plugin on only one implementation. If you're going to do it name it clangd-lsp. :)
Do you have a public repo? I'm super interested in contributing to this plugin.
The current code is very experimental and in a raw combination of both used and deprecated code, full of unreleasable log writes.
I will make a repo when I can clean up the code and after I do more debugging.
@pecan
It appears that processing the files is slow as per the logged info shown below:
Opening D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\CodeBlocks_wx31_64.cbp
Done.
cbProject::Open took: 0.725 seconds.
ProjectManager::SetProject took: 1.686 seconds.
ProjectManager::LoadProject took: 2.732 seconds.
ParseManager::CreateParser: Finish creating a new parser for project 'Code::Blocks wx3.1.x (64 bit)'
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\plugins\clangd_client\src\LSPclient\include\protocol.h (1441 ms) (496 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\plugins\clangd_client\src\codecompletion\parser\LSP_tokenizer.h (3194 ms) (495 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\plugins\clangd_client\src\codecompletion\codecompletion.cpp (4342 ms) (494 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\plugins\clangd_client\src\LSPclient\include\client.cpp (3738 ms) (493 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\include\compilerfactory.h (660 ms) (492 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\plugins\clangd_client\src\asyncprocess\asyncprocess.cpp (2228 ms) (491 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\sdk\configmanager-revision.cpp (3543 ms) (490 more)
LSP opened editor parse finished for D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\sdk\cygwin.cpp (3534 ms) (489 more)
LSP background parsing finished for: D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller\src\src\environmentsettingsdlg.cpp (3262 ms) (488 more)
Is there a way of speeding this up? Any ideas on where to look or what to check or do?
I am using MSYS2 with the latest updates as of a few hours ago (this resulted in waht looked like a big MinGW 64 9.00 run time update) and GCC 11.2.0.
@pecan.
I am not trying to be a PITA, but trying to give feedback and what I have seen when I see it so I do not forget....snipped...
@pecan
I have updated to the r8 code and it works better than the r5 as expected. As expected it's working allot better than the r5. It's probably worth putting up on the SF repo the plugin binary/zip file so people can test it with the nightly build. As for bug tracking can you enable the tickets tab in SF?
FYI. The following tickets have a codecompletion tag and are currently open, so when finished hopefully a heck of allot of these will get resolved:
Does anyone know of a good UTF8 char validator.
Clangd is handing back (occasionally) a 3 byte utf8 char.
It's blowing nlohmann json parser out of the water.
I'd like to scan the clangd stdout responses for invalid UTF8.
They're weird. \xE2\x80\xA6 right in the middle of an empty function() param area. Also that strange period half way up the middle of a char area. Like an item list indicator. \xE2\x80\xA2.
When, in the initialization, we tell clangd to use "Only UTF8", it's supposed to mean 8 bits only, not 24 bits. And evidently they don't know it, because they set the response length as if all chars are 8bit.
Thanks
Due to incompatibilities between plugins built with the latest MSYS2 and the nightly releases that cause then plugin to not load (unless you update the Mingw64 DLL's) there is an update of the plugin available that has been built using Mingw64 8.1.0. This update works with the nightly builds and also locally build C::B built with MSYS2 at:
https://sourceforge.net/projects/cb-clangd-client/files/
The install docs have been updated with a bunch of options for both the plugin and the clangd.exe.
instructions below for the specific compiler you haev installed:
File in SVN has been updated, so the next update will include the typo fixed.
Windows Clangd-Client Plugin install process:
============================================
1) Install the LLVM or Clangd.exe as documented in the following file:
Windows-LLVM-ClangD-Install-Readme.txt
2) Disable the Code completion plugin as follows:
a) Open the Plugin manager via the Code::Blocks "MainMenu=>Plugins=>Manage plugins..." menu
b) In the Manage Plugin dialog do the following:
i) Find and select the "Code completion" plugin via it's title
ii) Press the "Disable" button on the right near the top
iii) If you get any errors please try again.
3) Install the Clangd-Client Plugin using one of the following options, which are documneted later in this readme file:
a) Install via the Plugin Manager
b) Manaully install the plugin files
3) Configure the Clangd-Client Plugin for use as follows:
a) Select the "MainMenu=>Settings->Editor..." menu
b) In the list on the left click/select the "clangd_client" option.
c) In the "C/C++ parser" tab change the "Specify clangd executable to use" to reference the clangd.exe you installed via step 1) above.
Some examples of this could be:
C:\msys64\clang64\bin\clangd.exe
C:\msys64\clang32\bin\clangd.exe
C:\LLVM\bin\clangd.exe
C:\comilers\cmang\clangd.exe
@ollydbg In the plugin manager you specify the zip file instead of a .cbplugin and it works
MSYS2 Compiler - MinGW64
-------------------------
a) Install MSYS 2 clang packages via the msys2.exe bash shell:
pacman -S mingw-w64-clang-x86_64-toolchain
# pacman -S mingw-w64-clang-x86_64-toolchain
:: There are 22 members in group mingw-w64-clang-x86_64-toolchain:
:: Repository clang64
1) mingw-w64-clang-x86_64-clang 2) mingw-w64-clang-x86_64-clang-analyzer
3) mingw-w64-clang-x86_64-clang-tools-extra
4) mingw-w64-clang-x86_64-compiler-rt 5) mingw-w64-clang-x86_64-crt-git
6) mingw-w64-clang-x86_64-headers-git 7) mingw-w64-clang-x86_64-libc++
8) mingw-w64-clang-x86_64-libc++abi 9) mingw-w64-clang-x86_64-libmangle-git
10) mingw-w64-clang-x86_64-libunwind
11) mingw-w64-clang-x86_64-libwinpthread-git 12) mingw-w64-clang-x86_64-lld
13) mingw-w64-clang-x86_64-lldb 14) mingw-w64-clang-x86_64-llvm
15) mingw-w64-clang-x86_64-make 16) mingw-w64-clang-x86_64-mlir
17) mingw-w64-clang-x86_64-openmp 18) mingw-w64-clang-x86_64-pkgconf
19) mingw-w64-clang-x86_64-polly 20) mingw-w64-clang-x86_64-tools-git
21) mingw-w64-clang-x86_64-winpthreads-git
22) mingw-w64-clang-x86_64-winstorecompat-git
Enter a selection (default=all):
What is the encoding of your source file?
I see your latest commit here in rev 27
* clangd_client - Code to remove invalid utf8 chars from clangd responses; cf., client.cpp/h DoValidateUTF8data() (https://sourceforge.net/p/cb-clangd-client/code/27/)
I will test it, thanks!
EDIT updated:
The illegal utf8 problem still exits in rev 27. :(
// ----------------------------------------------------------------------------
void CodeCompletion::OnAttach()
// ----------------------------------------------------------------------------
{
AppVersion appVersion;
appVersion.m_AppName = "clangd_client";
// Set current plugin version
PluginInfo* pInfo = (PluginInfo*)(Manager::Get()->GetPluginManager()->GetPluginInfo(this));
pInfo->version = appVersion.GetVersion();
// ccmanager's config obtained from Menu=>Settings=>Editor=>Code Completion (sub panel)
// Get the CB config item that enables CodeCompletion
ConfigManager* ccmcfg = Manager::Get()->GetConfigManager(_T("ccmanager"));
m_CodeCompletionEnabled = ccmcfg->ReadBool(_T("/code_completion"), false);
if (not m_CodeCompletionEnabled)
{
pInfo->version = pInfo->version.BeforeFirst(' ') + " Inactive";
return;
}
D:\code\cb\cb_sf_git\cccrash2019\src\CodeBlocks_wx31_64.cbp
$(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks\plugins\clangd_client.dll
$(TARGET_DEVEL_DIR)\src\devel31_64
cmd /c if not exist $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks mkdir $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks
zip -jq9 $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks\clangd_client.zip src/resources/manifest.xml src/resources/*.xrc
zip -r9 $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks\clangd_client.zip src/resources/images > nul
Hi, I try to debug this plugin, but I have always have this line hit:
I have always get the m_CodeCompletionEnabled is false, and I have no idea how to enable it.
What I did is like below:
1, I have build a normal cbp:CodeD:\code\cb\cb_sf_git\cccrash2019\src\CodeBlocks_wx31_64.cbp
I just build it.
2, I just open the downloaded clangd_client project, and I changed some build options:
In the build option custom variables, I set the variable: TARGET_DEVEL_DIR
as the value: D:\code\cb\cb_sf_git\cccrash2019, which is the root folder of my local C::B git/svn
3, I changed the output filename as:Code$(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks\plugins\clangd_client.dll
which means the build target(clangd_client.dll) will be put in the same folder as the other core plugins.
4, I set the Execution working dir as:Code$(TARGET_DEVEL_DIR)\src\devel31_64
Which is the folder where codeblocks.exe locates.
5, I change the post build script as:Codecmd /c if not exist $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks mkdir $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks
zip -jq9 $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks\clangd_client.zip src/resources/manifest.xml src/resources/*.xrc
zip -r9 $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks\clangd_client.zip src/resources/images > nul
This means I make a clangd_client.zip, and put it in the destination devel31_64 folder.
@ollydbg
m_CodeCompletionEnabled variable refers to Settings/Editor/Code completion checkbox.
For your debugged CB, it must be currently unchecked which means neither Code completion nor clangd_client can run.
@ollydbg
When you run the debugger, CB ordinary uses the personality "default" which, for you, I'm guessing has CodeCompletion plugin enabled.
You should use a separate personality for debugging so that you can disable CodeCompletion in the debugged CB without disabling it in your production CB.
For me, in CB main menu/project/SetProgramArgument I have:
--debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen --verbose /p cbDebug315
Then I can disable CodeCompletion in the debugged CB MainMenu/plugins/managePlugins without it affecting the main CB personality "default".
I'd still like to see the "manage plugins" status of both clangd_client and Code Completion plugins to determine why your m_CodeCompletionEnabled variable is false.
@ollydbg
m_CodeCompletionEnabled variable refers to Settings/Editor/Code completion checkbox.
For your debugged CB, it must be currently unchecked which means neither Code completion nor clangd_client can run.
I have screen shots, see below as in attachment.
I have Settings/Editor/Code completion checkbox checked. If I member correctly this checkbox does not mean we should "disable" the plugin, instead, it means we don't show the suggestion prompt when we are editing.
The other screen shot shows the version latest version I'm using.
@ollydbg
m_CodeCompletionEnabled variable refers to Settings/Editor/Code completion checkbox.
For your debugged CB, it must be currently unchecked which means neither Code completion nor clangd_client can run.
I have screen shots, see below as in attachment.
I have Settings/Editor/Code completion checkbox checked. If I member correctly this checkbox does not mean we should "disable" the plugin, instead, it means we don't show the suggestion prompt when we are editing.
The other screen shot shows the version latest version I'm using.
I'll look into the historical usage of the Settings/Editor/Code completion box.
Are these snapshots form the debugger or the debuggee ?
clangd_client/clangd_client_wx31_64.cbp | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/clangd_client/clangd_client_wx31_64.cbp b/clangd_client/clangd_client_wx31_64.cbp
index 1af073c..eb3e6d4 100644
--- a/clangd_client/clangd_client_wx31_64.cbp
+++ b/clangd_client/clangd_client_wx31_64.cbp
@@ -6,8 +6,8 @@
<Option compiler="gcc" />
<Build>
<Target title="Clangd_Client-uw">
- <Option output="bin/Clangd_Client" prefix_auto="1" extension_auto="1" />
- <Option working_dir="bin31_64" />
+ <Option output="$(TARGET_DEVEL_DIR)/src/devel31_64/share/CodeBlocks/plugins/clangd_client" prefix_auto="1" extension_auto="1" />
+ <Option working_dir="$(TARGET_DEVEL_DIR)/src/devel31_64" />
<Option object_output=".objs31_64" />
<Option external_deps="$(CODEBLOCKS)/libcodeblocks.a;" />
<Option type="3" />
@@ -50,12 +50,13 @@
<Add before="cmd /c @echo CODEBLOCKS: $(CODEBLOCKS)" />
<Add before="cmd /c @echo TARGET_DEVEL_DIR: $(TARGET_DEVEL_DIR)" />
<Add before="g++ --version" />
- <Add after="cmd /c MakeRepoUpload.bat" />
+ <Add after="cmd /c if not exist $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks mkdir $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks" />
+ <Add after="zip -jq9 $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks\clangd_client.zip src/resources/manifest.xml src/resources/*.xrc" />
+ <Add after="zip -r9 $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks\clangd_client.zip src/resources/images" />
<Mode after="always" />
</ExtraCommands>
<Environment>
- <Variable name="TARGET_DEVEL_DIR" value="$(CODEBLOCKS)\..\.." />
- <Variable name="TARGET_DEVEL_DIR_AC" value="D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller" />
+ <Variable name="TARGET_DEVEL_DIR" value="D:\code\cb\cb_sf_git\cccrash2019" />
</Environment>
</Target>
<Environment>
zip -r9 $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks\clangd_client.zip src/resources/images
@ollydbg.
Well, I'm at a loss to figure out why that variable is false for you.
Somehow, clangd_client is seeing Setting/Editor/Code completion as unchecked in your CB .conf file.
This has nothing to do with your .cbp file. It's the contents of the .conf file that the debugger is using that's causing this problem.
wxString fileURI = fileUtils.FilePathToURI(infilename); //(ph 2022/01/5)
fileURI.Replace("\\", "/");
DocumentUri docuri = DocumentUri(fileURI.c_str());
cbStyledTextCtrl* pCntl = pcbEd->GetControl();
if (not pCntl) return false;
// save current length of the file
m_FileLinesHistory[pcbEd] = pCntl->GetLineCount();
wxString strText = pCntl->GetText();
const char* pText = strText.mb_str(); //works
writeClientLog(wxString::Format("<<< LSP_DidOpen:%s", docuri.c_str()) );
try { DidOpen(docuri, string_ref(pText, strText.Length()) ); }
catch(std::exception &err)
{
//printf("read error -> %s\nread -> %s\n ", e.what(), read.c_str());
wxString errMsg(wxString::Format("\nLSP_DidOpen() error: %s\n%s", err.what(), docuri.c_str()) );
writeClientLog(errMsg);
cbMessageBox(errMsg);
return false;
}
const char* pText = strText.mb_str();
Final word of caution: most of these functions may return either directly the pointer to internal string buffer or a temporary wxCharBuffer or wxWCharBuffer object. Such objects are implicitly convertible to char and wchar_t pointers, respectively, and so the result of, for example, wxString::ToUTF8() can always be passed directly to a function taking const char*. However code such asCodeconst char *p = s.ToUTF8();
...
puts(p); // or call any other function taking const char *
clangd_client/clangd_client_wx31_64.cbp | 11 ++++++-----
clangd_client/src/LSPclient/src/client.cpp | 4 ++--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/clangd_client/clangd_client_wx31_64.cbp b/clangd_client/clangd_client_wx31_64.cbp
index 1af073c..eb3e6d4 100644
--- a/clangd_client/clangd_client_wx31_64.cbp
+++ b/clangd_client/clangd_client_wx31_64.cbp
@@ -6,8 +6,8 @@
<Option compiler="gcc" />
<Build>
<Target title="Clangd_Client-uw">
- <Option output="bin/Clangd_Client" prefix_auto="1" extension_auto="1" />
- <Option working_dir="bin31_64" />
+ <Option output="$(TARGET_DEVEL_DIR)/src/devel31_64/share/CodeBlocks/plugins/clangd_client" prefix_auto="1" extension_auto="1" />
+ <Option working_dir="$(TARGET_DEVEL_DIR)/src/devel31_64" />
<Option object_output=".objs31_64" />
<Option external_deps="$(CODEBLOCKS)/libcodeblocks.a;" />
<Option type="3" />
@@ -50,12 +50,13 @@
<Add before="cmd /c @echo CODEBLOCKS: $(CODEBLOCKS)" />
<Add before="cmd /c @echo TARGET_DEVEL_DIR: $(TARGET_DEVEL_DIR)" />
<Add before="g++ --version" />
- <Add after="cmd /c MakeRepoUpload.bat" />
+ <Add after="cmd /c if not exist $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks mkdir $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks" />
+ <Add after="zip -jq9 $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks\clangd_client.zip src/resources/manifest.xml src/resources/*.xrc" />
+ <Add after="zip -r9 $(TARGET_DEVEL_DIR)\src\devel31_64\share\CodeBlocks\clangd_client.zip src/resources/images" />
<Mode after="always" />
</ExtraCommands>
<Environment>
- <Variable name="TARGET_DEVEL_DIR" value="$(CODEBLOCKS)\..\.." />
- <Variable name="TARGET_DEVEL_DIR_AC" value="D:\Andrew_Development\WorkingOnThese\AC-WindowsInstaller" />
+ <Variable name="TARGET_DEVEL_DIR" value="D:\code\cb\cb_sf_git\cccrash2019" />
</Environment>
</Target>
<Environment>
diff --git a/clangd_client/src/LSPclient/src/client.cpp b/clangd_client/src/LSPclient/src/client.cpp
index 3aa6956..6ae6afa 100644
--- a/clangd_client/src/LSPclient/src/client.cpp
+++ b/clangd_client/src/LSPclient/src/client.cpp
@@ -1053,7 +1053,7 @@ bool ProcessLanguageClient::DoValidateUTF8data(std::string& data)
char invChar = data[invloc]; // **debugging**
data[invloc] = ' '; //clear the invalid utf8 char
wxString msg = "Error: Removed clangd response invalid utf8 char:";
- msg << "\'" << invChar << "\'";
+ msg << "\'" << wxString::Format("%x", invChar ) << "\'";
Manager::Get()->GetLogManager()->DebugLog(msg);
}
}
@@ -1562,7 +1562,7 @@ bool ProcessLanguageClient::LSP_DidOpen(cbEditor* pcbEd)
m_FileLinesHistory[pcbEd] = pCntl->GetLineCount();
wxString strText = pCntl->GetText();
- const char* pText = strText.mb_str(); //works
+ const char* pText = strText.ToUTF8(); // ollydbg 2022-01-16
writeClientLog(wxString::Format("<<< LSP_DidOpen:%s", docuri.c_str()) );
msg << "\'" << wxString::Format("%x", invChar ) << "\'";
clangd_client/src/LSPclient/src/client.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clangd_client/src/LSPclient/src/client.cpp b/clangd_client/src/LSPclient/src/client.cpp
index 6ae6afa..88f5f8f 100644
--- a/clangd_client/src/LSPclient/src/client.cpp
+++ b/clangd_client/src/LSPclient/src/client.cpp
@@ -2443,7 +2443,7 @@ void ProcessLanguageClient::LSP_DidChange(cbEditor* pEd)
// Assure text is UTF8 before handing to DidChange()
didChangeEvent.text = edText;
- // didChangeEvent.text = edText.ToUTF8(); Trying to find bad utf8 problem
+ didChangeEvent.text = edText.ToUTF8(); //Trying to find bad utf8 problem
std::vector<TextDocumentContentChangeEvent> tdcce{didChangeEvent};
DocumentUri docuri = DocumentUri(fileURI.c_str());
// **debugging**
int ProcessLanguageClient::ReadLSPinputLength()
// ----------------------------------------------------------------------------
{
// this function is driven by readJson() via the thread in transport::loop()
// and the incoming data is locked.
// thread was started in constructor and called from readJason() after locking the buffer
// "Content-Length: <digits>\r\n\r\n"
if (Has_LSPServerProcess() and m_std_LSP_IncomingStr.length())
{
// search for LSP header
size_t hdrPosn = m_std_LSP_IncomingStr.find("Content-Length: ");
if (hdrPosn == std::string::npos)
return wxNOT_FOUND;
else //have incoming text
{
if (hdrPosn != 0) // verify LSP header is at beginning of buffer
{
// Error: header is not at beginning of buffer. Try to fix it.
// usually caused by clangd invalid utf8 sequence
wxString msg(wxString::Format("ERROR:%s(): buffLength (%d): Position of content header %d.\n",
__FUNCTION__, int(m_std_LSP_IncomingStr.length()), int(hdrPosn)) );
msg += "Buffer contents written to client log.";
#if defined(cb_DEBUG)
wxSafeShowMessage("Input Buffer error",msg);
#endif
msg += "LSP_IncomingStrBuf:\n" + m_std_LSP_IncomingStr + "\n";
writeClientLog(msg);
// adjust the data buf to get clangd header at buff beginning
m_std_LSP_IncomingStr = m_std_LSP_IncomingStr.substr(hdrPosn);
}
19:45:09.758 ERROR:ReadLSPinputLength(): buffLength (549): Position of content header 112.
Buffer contents written to client log.LSP_IncomingStrBuf:
":{"newText":"wxConvAuto($0)","range":{"end":{"character":16,"line":94},"start":{"character":12,"line":94}}}}]}}Content-Length: 414
{"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[{"category":"Parse Issue","code":"expected_unqualified_id","codeActions":[],"message":"Expected unqualified-id","range":{"end":{"character":14,"line":97},"start":{"character":12,"line":97}},"relatedInformation":[],"severity":1,"source":"clang"}],"uri":"file:///F:/test/Config.cpp","version":1}}
I see there are many pch files in the folder such as:
C:\Users\[myusername]\AppData\Local\Temp\preamble-c7460b.pch
I think those files is created by clangd, and are there any way to automatically delete them when exit C::B?
EDIT:
clangd writes too much disk : CPP-19402 (https://youtrack.jetbrains.com/issue/CPP-19402)
This discussion looks like the pch can keep in "memory". :)
clangd_client/src/LSPclient/src/client.cpp | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/clangd_client/src/LSPclient/src/client.cpp b/clangd_client/src/LSPclient/src/client.cpp
index 88f5f8f..f6b5eb9 100644
--- a/clangd_client/src/LSPclient/src/client.cpp
+++ b/clangd_client/src/LSPclient/src/client.cpp
@@ -266,6 +266,10 @@ ProcessLanguageClient::ProcessLanguageClient(const cbProject* pProject, const ch
command += " --limit-results=20"; // Limit the number of results returned by clangd. 0 means no limit (default=100)
+ // clangd writes too much disk : CPP-19402 https://youtrack.jetbrains.com/issue/CPP-19402
+ // "-pch-storage=memory"
+ command += " -pch-storage=memory";
+
if (wxDirExists(clangResourceDir))
command += " --resource-dir=" + clangResourceDir; // Directory for system includes
m_MutexInputBufGuard.Lock;
m_MutexInputBufGuard.Unlock();
I see some error message comes from this function call, but I'm not sure why, this happens when I'm editing source file in the C::B editor.Codeint ProcessLanguageClient::ReadLSPinputLength()
// ----------------------------------------------------------------------------
{
// this function is driven by readJson() via the thread in transport::loop()
// and the incoming data is locked.
// thread was started in constructor and called from readJason() after locking the buffer
// "Content-Length: <digits>\r\n\r\n"
if (Has_LSPServerProcess() and m_std_LSP_IncomingStr.length())
{
// search for LSP header
size_t hdrPosn = m_std_LSP_IncomingStr.find("Content-Length: ");
if (hdrPosn == std::string::npos)
return wxNOT_FOUND;
else //have incoming text
{
if (hdrPosn != 0) // verify LSP header is at beginning of buffer
{
// Error: header is not at beginning of buffer. Try to fix it.
// usually caused by clangd invalid utf8 sequence
wxString msg(wxString::Format("ERROR:%s(): buffLength (%d): Position of content header %d.\n",
__FUNCTION__, int(m_std_LSP_IncomingStr.length()), int(hdrPosn)) );
msg += "Buffer contents written to client log.";
#if defined(cb_DEBUG)
wxSafeShowMessage("Input Buffer error",msg);
#endif
msg += "LSP_IncomingStrBuf:\n" + m_std_LSP_IncomingStr + "\n";
writeClientLog(msg);
// adjust the data buf to get clangd header at buff beginning
m_std_LSP_IncomingStr = m_std_LSP_IncomingStr.substr(hdrPosn);
}
I just enabled the log file, and see the log message(in C:\Users\[myusername]\AppData\Local\Temp\CBclangd_client-1332.log
And the content of the log file are:Code19:45:09.758 ERROR:ReadLSPinputLength(): buffLength (549): Position of content header 112.
Buffer contents written to client log.LSP_IncomingStrBuf:
":{"newText":"wxConvAuto($0)","range":{"end":{"character":16,"line":94},"start":{"character":12,"line":94}}}}]}}Content-Length: 414
{"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[{"category":"Parse Issue","code":"expected_unqualified_id","codeActions":[],"message":"Expected unqualified-id","range":{"end":{"character":14,"line":97},"start":{"character":12,"line":97}},"relatedInformation":[],"severity":1,"source":"clang"}],"uri":"file:///F:/test/Config.cpp","version":1}}
I see there are many pch files in the folder such as:
C:\Users\[myusername]\AppData\Local\Temp\preamble-c7460b.pch
I think those files is created by clangd, and are there any way to automatically delete them when exit C::B?
EDIT:
clangd writes too much disk : CPP-19402 (https://youtrack.jetbrains.com/issue/CPP-19402)
This discussion looks like the pch can keep in "memory". :)
Here is the patch to fix this pch file issue:Codeclangd_client/src/LSPclient/src/client.cpp | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/clangd_client/src/LSPclient/src/client.cpp b/clangd_client/src/LSPclient/src/client.cpp
index 88f5f8f..f6b5eb9 100644
--- a/clangd_client/src/LSPclient/src/client.cpp
+++ b/clangd_client/src/LSPclient/src/client.cpp
@@ -266,6 +266,10 @@ ProcessLanguageClient::ProcessLanguageClient(const cbProject* pProject, const ch
command += " --limit-results=20"; // Limit the number of results returned by clangd. 0 means no limit (default=100)
+ // clangd writes too much disk : CPP-19402 https://youtrack.jetbrains.com/issue/CPP-19402
+ // "-pch-storage=memory"
+ command += " -pch-storage=memory";
+
if (wxDirExists(clangResourceDir))
command += " --resource-dir=" + clangResourceDir; // Directory for system includes
I see there are some code snippet like:Codem_MutexInputBufGuard.Lock;
m_MutexInputBufGuard.Unlock();
But in the code, we have to carefully handle the unlocking the wxMutex when return the function body, especially when there are multiply returns.
Is it possible to use the wxMutexLocker, and check the IsOK() function for checking whether it get locked or not.
I see there are some code snippet like:Codem_MutexInputBufGuard.Lock;
m_MutexInputBufGuard.Unlock();
But in the code, we have to carefully handle the unlocking the wxMutex when return the function body, especially when there are multiply returns.
Is it possible to use the wxMutexLocker, and check the IsOK() function for checking whether it get locked or not.
There are only 2 locks in the code that can cause any trouble. The lock on the input buffer. One to write to the buffer, and one to get the next clangd response out of the buffer. And neither affect the UI thread.
I tried wxMutexLocker first before giving up on it.
I want to be able to unlock the input buffer and then do more work in the function.
When I unlocked the mutex before the function ended, wxWidgets gave me errors about the mutex. I lost confidence that I could mix a wxMutexLocker and manual unlocks.
In fact, I removed all locks on the main UI thread and used idle time callbacks instead.
BTW: since the console pipe is connected with clangd.exe, I'm not sure why the locker is needed. Since the content is from a thread to the main GUI thread by the Event, when you got the Event, you were already in the main GUI thread, and the content in the Event(wxThreadEvent) is already deep copied. So, I think the locker is not necessary, am I correct?
BTW: since the console pipe is connected with clangd.exe, I'm not sure why the locker is needed. Since the content is from a thread to the main GUI thread by the Event, when you got the Event, you were already in the main GUI thread, and the content in the Event(wxThreadEvent) is already deep copied. So, I think the locker is not necessary, am I correct?
There are two non main UI threads accessing the clangd input buffer. The pipe thread and the ReadJson thread. Without the lock I assume the ReadJason thread could remove data at the same time the pipe "ProcessEvent" was writing to the (UI client.h) std::string buffer.
the "locks failed" messages could be coming from attempts to lock the symbols tree (comsuming). But it's ok. If the symbols tree update thread can't get the lock. Its ok to block.
If the lock fails in :LSP_ParseDocumentSymbols (stows symbols in tree), it just requeues itself for an idle time callback. It does not block.
FYI:
I have make a simple wiki page:
CB Clangd Client - Code::Blocks (https://wiki.codeblocks.org/index.php/CB_Clangd_Client)
;)
clangd_client/src/LSPclient/src/client.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clangd_client/src/LSPclient/src/client.cpp b/clangd_client/src/LSPclient/src/client.cpp
index 459b809..e03730d 100644
--- a/clangd_client/src/LSPclient/src/client.cpp
+++ b/clangd_client/src/LSPclient/src/client.cpp
@@ -1073,7 +1073,7 @@ bool ProcessLanguageClient::DoValidateUTF8data(std::string& data)
std::string invStr(&data[invloc], 1);
//unsigned int invInt = (unsigned int)data[invloc];
unsigned char invChar(invStr[0]);
- wxUniChar uniChar(invChar);
+ wxUniChar uniChar((unsigned int)invChar);
// clangd response:
// {"id":"textDocument/completion","jsonrpc":"2.0","result":{
wxUniChar::wxUniChar ( unsigned char c )
Create a character from the 8-bit character value c using the current locale encoding.
CB Clangd Client / Code / Commit [r32] (https://sourceforge.net/p/cb-clangd-client/code/32/)
Please note that in this revision.
I'm using the Windows clangd_client_wx31_64.cbp
The generated dll file name is: Clangd_Client.dll
And the zip file name is: clangd_client.zip
Do you think the name should be the same? I mean to keep the case consistent.
Error: Removed clangd response invalid utf8 char:position(3665), hex(85), U(2026), <cant post> ResponseID:textDocument/completion
Error: Removed clangd response invalid utf8 char:position(6899), hex(85), U(85), ,<cant post on sf>. ResponseID:textDocument/completion
msg += wxString::Format("position(%d), hex(%02hhX), U(%x), \'%s\'", invloc, (unsigned int)invChar, (int)uniChar.GetValue(), invStr );
The plugin spec says they need to be the same. I cannot remember which OS or if it was the plugin, but case differences have caused me problems. I missed this one when comparing CodeBlocks_wx31_64.cbp and clangd_client_wx31_64.cbp changes for the plugin as my CodeBlocks_wx31_64.cbp has the following line for the output:
<Option output="devel31_64/share/CodeBlocks/plugins/clangd_client" prefix_auto="1" extension_auto="1" />
@ ollydbg
This change didn't work for me. (Message #69)
I want the codepoint. I don't get any asserts.
With "wxUniChar uniChar(invChar);" I get:CodeNote that I get the codepoint U(2026) back.Error: Removed clangd response invalid utf8 char:position(3665), hex(85), U(2026), <cant post> ResponseID:textDocument/completion
With "wxUniChar uniChar(unsigned int(invChar));" I get:CodeHere I get only the hex value.Error: Removed clangd response invalid utf8 char:position(6899), hex(85), U(85), ,<cant post on sf>. ResponseID:textDocument/completion
So I changed the wxString::Format to:CodeNote the "(int)uniChar.GetValue()"msg += wxString::Format("position(%d), hex(%02hhX), U(%x), \'%s\'", invloc, (unsigned int)invChar, (int)uniChar.GetValue(), invStr );
I'm using wx3.1.5 on windows and wx3.0 on linux.
Works with no asserts.
Does it work for you
unsigned char invChar = 0x83;
wxUniChar uniChar(invChar);
wxString msg = wxString::Format("hex(%02hhX), U(%x)", (unsigned int)invChar, uniChar.GetValue());
wxLogMessage(msg);
unsigned char invChar = 0x83;
wxUniChar uniChar((unsigned int)invChar);
wxString msg = wxString::Format("hex(%02hhX), U(%x)", (unsigned int)invChar, uniChar.GetValue());
wxLogMessage(msg);
Note: it took me 45 minutes to post this. Don't try and post a msg with an invalid utf8 char. It's a PITAI also meet this kind of forum error from time to time. So bad.
clangd_client/src/LSPclient/src/client.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/clangd_client/src/LSPclient/src/client.cpp b/clangd_client/src/LSPclient/src/client.cpp
index fadcb51..459b809 100644
--- a/clangd_client/src/LSPclient/src/client.cpp
+++ b/clangd_client/src/LSPclient/src/client.cpp
@@ -702,9 +702,9 @@ void ProcessLanguageClient::OnLSP_Terminated(wxThreadEvent& event_pipedprocess_t
wxCommandEvent terminatedEvt(wxEVT_COMMAND_MENU_SELECTED, XRCID("idLSP_Process_Terminated"));
terminatedEvt.SetEventObject((wxObject*)m_pCBProject);
terminatedEvt.SetInt(processExitCode);
- Manager::Get()->GetAppFrame()->GetEventHandler()->ProcessEvent(terminatedEvt)
+ Manager::Get()->GetAppFrame()->GetEventHandler()->ProcessEvent(terminatedEvt);
-; if (processExitCode != 0)
+ if (processExitCode != 0)
{
wxString msg = "Unusual termination of LanguageProcessClient(LSP) occured.";
if (lspClientLogFile.IsOpened() )
The changes in commit r12689 may apply to this plugin.
ConfigManager *cfgApp = Manager::Get()->GetConfigManager(_T("app"));
bool i18n = cfgApp->ReadBool(_T("/locale/enable"), false);
One issue I see when using this plugin to parse the "Code::Blocks wx3.1.x (64bit)" cbp file.
In my computer, it takes more than 15 minutes, but from the "Code::Blocks Debug" log, I still see there are more than 280 more files need to be parsed. I see the "clangd.exe" eat about 75% of my cpu usage.
Is there option that we can only parse the active cpp files? Or active target source files. It looks like parsing the whole projects is really slow. :(
Thanks.
One issue I see when using this plugin to parse the "Code::Blocks wx3.1.x (64bit)" cbp file.
In my computer, it takes more than 15 minutes, but from the "Code::Blocks Debug" log, I still see there are more than 280 more files need to be parsed. I see the "clangd.exe" eat about 75% of my cpu usage.
Is there option that we can only parse the active cpp files? Or active target source files. It looks like parsing the whole projects is really slow. :(
Thanks.
You do not have to wait for all files to parse to use clangd.
Re: cpu usage. Set concurrently parsing threads to 2 at
Setting->Editor->Clangd_Client->C.C++ parser(tab)->Concurrently parsing threads.
You should not worry about parsing going on in the background when restricting the number of parsing threads. My cpu usage is only 34% when I restrict concurrent parsing to 2 threads. And clangd response is quite fast.
(Intel i7 with 8 threads), only half of the threads are allowed to be used by clangd (hard coded), and only 2 to be used for background parsing (user option).
Active editors always get parsed first, then inactive editors, then background (non-editor) files. Newly opened editors go to the head of the queue and get parsed ahead of background files. Code completion requests also go to the head of queue.
There's no need to wait after the active editor is parsed (3 to 7 secs).
When I open CodeBlocks workspace (31_64), the active editor is indexed by clangd in a max of 7 seconds. All open editors have been indexed in less than 30 seconds. But I never have to wait more then 7 seconds to use code completion or other clangd features.
All those files being parsed in the background are used to fill the symbols tree. They're parsed in order of last-changed-time, then last-opened-time then all others so that the symbols tree gets filled with the most likely used files and symbols.
However, I'll put your suggestion in the ToDo list with an option to only parse files in editors. I don't know why you'd want to do that though, if you'll restrict the number of concurrent parsing threads.
Maybe, the background index can be saved when we close the project, and reopen it when we load the project.
Here are some reference:
Qt Creator and clangd: An Introduction (https://www.qt.io/blog/qt-creator-and-clangd-an-introduction)
It said the index can be persistent.
Some from clangd and llvm github and forum
Ability to move a project's clangd background index without triggering reindexing Issue #847 clangd/clangd (https://github.com/clangd/clangd/issues/847)
and Offline background index preparation Issue #587 clangd/clangd (https://github.com/clangd/clangd/issues/587)
and Using background and static indexes simultaneously for large codebases - Clang Frontend / clangd - LLVM Discussion Forums (https://discourse.llvm.org/t/using-background-and-static-indexes-simultaneously-for-large-codebases/3706)
// 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();
}
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: 系统找不到指定的文件。)
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
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.
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:Code19: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 (https://github.com/asmwarrior/wxModularApp)
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 (https://sourceforge.net/p/cb-clangd-client/code/HEAD/tree/trunk/clangd_client/documentation-install/Windows-LLVM-ClangD-Install-Readme.txt)
It said:CodeMSYS2 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. :)
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.
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?
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)
ConfigManager* cfg = Manager::Get()->GetConfigManager(_T("clangd_client"));
wxString cfgClangdMasterPath = cfg->Read("/LLVM_MasterPath", wxString());
$(TARGET_COMPILER_DIR)bin\clangd.exe
$(TARGET_COMPILER_DIR)bin\gdb.exe
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 ?
pacman -R $(pacman -Qsq 'mingw-w64-clang-x86_64*')
Is it possible to enable macro expansion for the llvm master path?Code$(TARGET_COMPILER_DIR)bin\clangd.exe
TypeA a;
typedef TypeB TypeA;
[Window Title]
LSP OnGotoDeclaration
[Content]
The editor's file does not have an associated project.
Perhaps add the file to a project ?
[OK]
and what does it do with :
using TypeA = TypeB;
#include "TypeA.h"
int main()
{
TypeA a;
return 0;
}
#include "TypeB.h"
// typedef TypeB TypeA;
using TypeA = TypeB;
class TypeB
{
public:
int abc;
};
// ----------------------------------------------------------------------------
void CodeCompletion::OnGotoDeclaration(wxCommandEvent& event)
// ----------------------------------------------------------------------------
{
ProjectManager* pPrjMgr = Manager::Get()->GetProjectManager();
cbProject* pActiveProject = pPrjMgr->GetActiveProject();
if (not GetLSPclient(pActiveProject)) return;
EditorManager* pEdMgr = Manager::Get()->GetEditorManager();
cbEditor* pActiveEditor = pEdMgr->GetBuiltinActiveEditor();
if (!pActiveEditor)
return;
TRACE(_T("OnGotoDeclaration"));
const int pos = pActiveEditor->GetControl()->GetCurrentPos();
const int startPos = pActiveEditor->GetControl()->WordStartPosition(pos, true);
const int endPos = pActiveEditor->GetControl()->WordEndPosition(pos, true);
wxString targetText;
targetText << pActiveEditor->GetControl()->GetTextRange(startPos, endPos);
if (targetText.IsEmpty())
return;
// prepare a boolean filter for declaration/implementation
bool isDecl = event.GetId() == idGotoDeclaration || event.GetId() == idMenuGotoDeclaration;
bool isImpl = event.GetId() == idGotoImplementation || event.GetId() == idMenuGotoImplementation;
// ----------------------------------------------------------------------------
// LSP Goto Declaration/definition //(ph 2020/10/12)
// ----------------------------------------------------------------------------
bool usingLSP_client = true;
if (usingLSP_client)
{
// Assure editors file belongs to the active project (else it's not parsed yet).
ProjectFile* pProjectFile = pActiveEditor->GetProjectFile();
cbProject* pEdProject = pProjectFile ? pProjectFile->GetParentProject() : nullptr;
wxString filename = pActiveEditor->GetFilename();
if ( (not pEdProject)
//?or (not (pEdProject == pActiveProject)) //(ph 2022/02/15)
//?or (not pActiveProject->GetFileByFilename(filename,false)) //(ph 2022/02/15)
or (not GetLSPclient(pEdProject))
)
{
//? InfoWindow::Display("LSP " + wxString(__FUNCTION__), "Editor's file is not contained in the active project.", 6000); //(ph 2022/02/15)
wxString msg = _("The editor's file does not have an associated ");
if (not pEdProject)
msg << _("project.") << _("\nPerhaps add the file to a project ?");
else if (not GetLSPclient(pEdProject))
msg << "clangd_client." << _("\nPerhaps the project needs to be reparsed ?");
cbMessageBox(msg, "LSP " + wxString(__FUNCTION__));
return;
}
If I looked at the comment "// Assure editors file belongs to the active project (else it's not parsed yet)."
I think it is not correct, I'm not sure clangd has some feature to query if a file is parsed or not, any one know the research direction?-server-protocol[/url]
If I looked at the comment "// Assure editors file belongs to the active project (else it's not parsed yet)."
I think it is not correct, I'm not sure clangd has some feature to query if a file is parsed or not, any one know the research direction?-server-protocol[/url]
I apologize for not responding. But I'm in the middle of the US tax season. I'll respond as soon as I can get my head out of the tax instructions.
This is not a clangd problem.
It's a "this programmer failed to implement sending non-project files to clangd" problem.
The current rev 50 of clangd_client adds support to load and parse non-project files (some project must be active), allow macros in clangd installation path and fixes assorted crash and logic errors.
-------------- Build: Clangd_Client-wx31_64 in Clangd_Client-wx31_64 (compiler: GNU GCC Compiler)---------------
[ 33.3%] Running target pre-build steps
[ 66.7%] cmd /c @echo TARGET_OUTPUT_DIR: devel31_64\
TARGET_OUTPUT_DIR: devel31_64\
[100.0%] cmd /c @echo TARGET_OUTPUT_FILENAME: clangd_client.dll
TARGET_OUTPUT_FILENAME: clangd_client.dll
cmd /c @ECHO TARGET_DEVEL_DIR: D:\code\cb\cb_sf_git\cccrash2019
TARGET_DEVEL_DIR: D:\code\cb\cb_sf_git\cccrash2019
[ 3.4%] g++.exe -Wall -std=gnu++17 -m64 -g -g -pipe -mthreads -fmessage-length=0 -fexceptions -DHAVE_W32API_H -DBUILDING_PLUGIN -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DNOPCH -DwxUSE_UNICODE -D_WIN64 -DCC_NO_COLLAPSE_ITEM -DLOGGING -DDONT_SHOW_SERVER_CONSOLE -ID:\code\cb\cb_sf_git\cccrash2019\src\include -ID:\code\cb\cb_sf_git\cccrash2019\src\sdk\wxscintilla\include\ -ID:\code\cb\cb_sf_git\cccrash2019\src\include\tinyxml\ -ID:\code\cb\clangd_plugin\trunk\clangd_client\src -Isrc -Isrc\LSPclient\include -Isrc\winprocess -Isrc\winprocess\asyncprocess -Isrc\winprocess\misc -IF:\code\wxWidgets-3.1.6\include -IF:\code\wxWidgets-3.1.6\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Iinclude\tinyxml -Isrc\LSPclient -c D:\code\cb\clangd_plugin\trunk\clangd_client\src\codecompletion\codecompletion.cpp -o .obj\clangd_client\src\codecompletion\codecompletion.o
D:\code\cb\clangd_plugin\trunk\clangd_client\src\codecompletion\codecompletion.cpp: In member function 'ProcessLanguageClient* CodeCompletion::CreateNewLanguageServiceProcess(cbProject*)':
D:\code\cb\clangd_plugin\trunk\clangd_client\src\codecompletion\codecompletion.cpp:2995:25: error: 'class ProcessLanguageClient' has no member named 'SetParser'
2995 | pLSPclient->SetParser( static_cast<Parser*>(pParser));
| ^~~~~~~~~
D:\code\cb\clangd_plugin\trunk\clangd_client\src\codecompletion\codecompletion.cpp: In member function 'void CodeCompletion::DoParseOpenedProjectAndActiveEditor(wxTimerEvent&)':
D:\code\cb\clangd_plugin\trunk\clangd_client\src\codecompletion\codecompletion.cpp:4747:23: error: 'class ProcessLanguageClient' has no member named 'SetParser'
4747 | pProxyClient->SetParser((Parser*)pProxyParser);
| ^~~~~~~~~
Process terminated with status 1 (0 minute(s), 13 second(s))
2 error(s), 0 warning(s) (0 minute(s), 13 second(s))
if (pParser)
{
pParser->SetLSP_Client(pLSPclient);
// Create ProxyProject move to OnAppDoneStartup() //(ph 2022/04/16)
//// // Create a ProxyProject to use for non-project files (if not already existent )
//// GetParseManager()->SetProxyProject(pcbProject);
//// // Set the ProxyProject to share this clangd client.
//// cbProject* pProxyProject = GetParseManager()->GetProxyProject();
//// if (pProxyProject)
//// {
//// m_LSP_Clients[GetParseManager()->GetProxyProject()] = pLSPclient;
//// ParserBase* pProxyParser = GetParseManager()->GetParserByProject(pProxyProject);
//// pProxyParser->SetLSP_Client(pLSPclient);
//// }
pLSPclient->SetParser( static_cast<Parser*>(pParser));
}
pLSPclient->LSP_Initialize(pcbProject);
}
cb_clang\clangd_client\src\codecompletion\parser\parser.cpp|1405|error: 'class ProcessLanguageClient' has no member named 'GetClientsCBProject'; did you mean 'GetClientObject'?|
cb_clang\clangd_client\src\codecompletion\codecompletion.cpp|2995|error: 'class ProcessLanguageClient' has no member named 'SetParser'|
cb_clang\clangd_client\src\codecompletion\codecompletion.cpp|4747|error: 'class ProcessLanguageClient' has no member named 'SetParser'|
I have no idea why Tortoise svn hates me so much.
Rev 52 should now have the correct files.
I downloaded and compiled it ok.
Thanks guys !!
In rev 52, why do you add a clangd_client.zip file to the repo?
...snip...
CC_ProxyProject.cbp, what does this cbp file used for?
I'm using the latest nightly in a Windows 7 pro 64 bit OS and for the first time I tested your implementation of the code completion using Clangd. Overall I like it and it's working but I have the following comments.
I'm building this plugin with the latest wx 3.2.0 release.
The source code I use is the latest rev: [r67] (https://sourceforge.net/p/cb-clangd-client/code/67/)
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] (https://sourceforge.net/p/cb-clangd-client/code/66/), 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.
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?
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;
$(TARGET_COMPILER_DIR)../usr/bin
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?
I'm using C::B for my own big project.
Let me create a minimal project for testing(reproduce this bug)
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":[]}
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"}]}
LSP diagnostics: JsonRead.cpp|:|----Time: 11:30:08.905---- (0 diagnostics)|
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;
}
// 上面的函数
-------------------- 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
-------------------- 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**
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:Code09: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;
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 stringCode$(TARGET_COMPILER_DIR)../usr/bin
So, it looks like the TARGET_COMPILER_DIR is not replaced by the "F:\code\msys2-64\mingw64".[/code]
wxString envPath;
wxGetEnv("PATH", &envPath);
logLine = "SystemPath: " + envPath;
writeClientLog(logLine);
I stripped down to a minimal code snippet: (you should save the code to UTF8 format)Codeint 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;
}
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// 上面的函数
Then, everything works expected.
Can you guys reproduce this bug?
Thanks.
...snip...
10:37:36.951 <<< GoToDeclaration:
file:///C:/temp/OllyDbgGoToDeclConsole/main.cpp,line[27], char[14]
10:37:36.951 <<< Content-Length: 207
{"id":"textDocument/declaration","jsonrpc":"2.0","method":"textDocument/declaration","params":{"position":{"character":14,"line":27},"textDocument":{"uri":"file:///C:/temp/OllyDbgGoToDeclConsole/main.cpp"}}}
10:37:37.041 >>> readJson() len:196:
{"id":"textDocument/declaration","jsonrpc":"2.0","result":[{"range":{"end":{"character":48,"line":23},"start":{"character":41,"line":23}},"uri":"file:///C:/temp/OllyDbgGoToDeclConsole/main.cpp"}]}
I stripped down to a minimal code snippet: (you should save the code to UTF8 format)Codeint 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;
}
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// 上面的函数
Then, everything works expected.
Can you guys reproduce this bug?
Thanks.
...snip...
I am unable to re-produce this error.
Find declaration of strUtf8 jumps to the strUtf8 parameter.
Here's the log entry.Code10:37:36.951 <<< GoToDeclaration:
file:///C:/temp/OllyDbgGoToDeclConsole/main.cpp,line[27], char[14]
10:37:36.951 <<< Content-Length: 207
{"id":"textDocument/declaration","jsonrpc":"2.0","method":"textDocument/declaration","params":{"position":{"character":14,"line":27},"textDocument":{"uri":"file:///C:/temp/OllyDbgGoToDeclConsole/main.cpp"}}}
10:37:37.041 >>> readJson() len:196:
{"id":"textDocument/declaration","jsonrpc":"2.0","result":[{"range":{"end":{"character":48,"line":23},"start":{"character":41,"line":23}},"uri":"file:///C:/temp/OllyDbgGoToDeclConsole/main.cpp"}]}
Attached: a .zip of a .wmv recording the sucessful behavior.
@OllyDbg
I still use wx3.1.5 and the compiler used by the nightly.
I always compile, debug and publish with the wx that's used with the nightly.
I've noticed that clangd can behave peculiarly if a request is made to it and a previous error exists. When I correct any previous error, the subsequent clangd requests tend to work.
See if fixing the main functions "return int" fixes the problem. Just a guess...
Thanks for all your testing.
I will try to rebuild the C::B and clangd_client plugin with wx 3.1.7 later today to see whether it is the wx related issue.
20:25:11.290 <<< Content-Length: 614
{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"languageId":"cpp","text":"\r\n\r\n\r\n\r\nint abc;\r\n\r\n\r\nint main()\r\n{\r\n abc = 3;\r\n return 0;\r\n}\r\n\r\n\r\n#include <string>\r\n\r\n\r\nstd::string Utf8ToGbk(const std::string& strUtf8);\r\n\r\nstd::string Utf8ToGbk(const std::string& strUtf8)\r\n{\r\n // 上面的函数\r\n // return unicodeString.ToStdString(); 默认使用当前操作系统的编码格式,Windows通常为GB2312\r\n return strUtf8;\r\n}\r\n\r\n\r\n\r\n","uri":"file:///D:/project/test5-readtext/a.cpp","version":0}}}
20:27:05.074 <<< Content-Length: 185
{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"languageId":"cpp","text":"","uri":"file:///D:/test5-readtext/a.cpp","version":0}}}
@@ -1664,9 +1683,13 @@ bool ProcessLanguageClient::LSP_DidOpen(cbEditor* pcbEd)
// save current length of the file
m_FileLinesHistory[pcbEd] = pCntl->GetLineCount();
- wxString strText = pCntl->GetText();
- //-const char* pText = strText.mb_str(); //works //(ph 2022/01/17)
- const char* pText = strText.ToUTF8(); //ollydbg 220115 did not solve illegal utf8char
+ #if wxCHECK_VERSION(3,1,5) //3.1.5 or higher
+ wxString strText = pCntl->GetText().utf8_string(); //solves most illegal utf8chars
+ #else
+ //const char* pText = strText.mb_str(); //works //(ph 2022/01/17)
+ wxString strText = pCntl->GetText().ToUTF8(); //ollydbg 220115 did not solve illegal utf8chars
+ #endif
+ const char* pText = strText.c_str();
OK, it looks like the change in rev67 is here:Code@@ -1664,9 +1683,13 @@ bool ProcessLanguageClient::LSP_DidOpen(cbEditor* pcbEd)
// save current length of the file
m_FileLinesHistory[pcbEd] = pCntl->GetLineCount();
- wxString strText = pCntl->GetText();
- //-const char* pText = strText.mb_str(); //works //(ph 2022/01/17)
- const char* pText = strText.ToUTF8(); //ollydbg 220115 did not solve illegal utf8char
+ #if wxCHECK_VERSION(3,1,5) //3.1.5 or higher
+ wxString strText = pCntl->GetText().utf8_string(); //solves most illegal utf8chars
+ #else
+ //const char* pText = strText.mb_str(); //works //(ph 2022/01/17)
+ wxString strText = pCntl->GetText().ToUTF8(); //ollydbg 220115 did not solve illegal utf8chars
+ #endif
+ const char* pText = strText.c_str();
This code change looks wrong (cause my issue) here.
[Window Title]
codeblocks.exe
[Content]
LSP: trying to get AST for non-added document
[OK]
There are some other issues in rev67, which I never see in rev66.
When editing the comments, I got this message box:Code[Window Title]
codeblocks.exe
[Content]
LSP: trying to get AST for non-added document
[OK]
I really don't know why this will happen.
OK, it looks like the change in rev67 is here:Code@@ -1664,9 +1683,13 @@ bool ProcessLanguageClient::LSP_DidOpen(cbEditor* pcbEd)
// save current length of the file
m_FileLinesHistory[pcbEd] = pCntl->GetLineCount();
- wxString strText = pCntl->GetText();
- //-const char* pText = strText.mb_str(); //works //(ph 2022/01/17)
- const char* pText = strText.ToUTF8(); //ollydbg 220115 did not solve illegal utf8char
+ #if wxCHECK_VERSION(3,1,5) //3.1.5 or higher
+ wxString strText = pCntl->GetText().utf8_string(); //solves most illegal utf8chars
+ #else
+ //const char* pText = strText.mb_str(); //works //(ph 2022/01/17)
+ wxString strText = pCntl->GetText().ToUTF8(); //ollydbg 220115 did not solve illegal utf8chars
+ #endif
+ const char* pText = strText.c_str();
This code change looks wrong (cause my issue) here.
I just revert this changes in rev67, and rebuild the clangd_client plugin, and my issue is gone! :)
Question: Do you NOT use utf8 in CB editors?
The line containing " wxString strText = pCntl->GetText().utf8_string();" was advertised as solving non-utf8 chars in a buffer. And does so for me.
What editor encoding do you use?
There are some other issues in rev67, which I never see in rev66.
When editing the comments, I got this message box:Code[Window Title]
codeblocks.exe
[Content]
LSP: trying to get AST for non-added document
[OK]
I really don't know why this will happen.
Acknowledge. I get this when adding a new file to the project. Specifically (for me) MainMenu/File/new/file...
It's caused because CB invokes OnEditorActivated() before setting the editor's ProjectFile member (pointing to the parent project) and ~proxyProject~ grabs it thinking it's a non-project file.
It'll be fixed in the next commit.
[Window Title]
codeblocks.exe
[Content]
LSP_DidChange error: [json.exception.type_error.316] invalid UTF-8 byte at index 4: 0xB4
file:///D:/project/abc.cpp
[OK]
@@ -2585,7 +2609,12 @@ void ProcessLanguageClient::LSP_DidChange(cbEditor* pEd)
///- hasChangedLineCount = true; //(ph 2021/07/26) //(ph 2021/10/11) clangd v13 looks ok
if ( (hasChangedLineCount) or (lineChangedNbr >= oldLineCount-1) )
// send the whole editor text to the server.
- edText = pCtrl->GetText();
+ // Assure text is UTF8 before handing to DidChange()
+ #if wxCHECK_VERSION(3,1,5) //3.1.5 or higher
+ edText = pCtrl->GetText().utf8_string(); //(ph 2022/06/22)
+ #else
+ edText = pCtrl->GetText().ToUTF8();
+ #endif
else
{
// send only the one line that changed. //(send previous, current, and next line maybe??)
@@ -2599,9 +2628,7 @@ void ProcessLanguageClient::LSP_DidChange(cbEditor* pEd)
didChangeEvent.range = range;
}
- // Assure text is UTF8 before handing to DidChange()
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**
wxString edText;
// If line count has changed, send full text, else send changed line.
// Also, special handling for last line of text
///- hasChangedLineCount = true; //(ph 2021/07/26) //(ph 2021/10/11) clangd v13 looks ok
if ( (hasChangedLineCount) or (lineChangedNbr >= oldLineCount-1) )
// send the whole editor text to the server.
// Assure text is UTF8 before handing to DidChange()
#if wxCHECK_VERSION(3,1,5) //3.1.5 or higher
edText = pCtrl->GetText().utf8_string(); //(ph 2022/06/22)
#else
edText = pCtrl->GetText().ToUTF8();
#endif
else
{
// send only the one line that changed. //(send previous, current, and next line maybe??)
edText = lineText;
Range range;
range.start.line = lineChangedNbr;
range.start.character = lineBeginCol;
range.end.line = lineEndNbr+1;
range.end.character = 0;
//didChangeEvent.rangeLength = lineText.Length(); dont use. it's been deprecated
didChangeEvent.range = range;
}
didChangeEvent.text = edText;
...snipped...
I think the variable "edText" should have the std::string type, not the wxString.
Also, if possible this line
edText = lineText;
Should also be adjusted because lineText is wxString, while edText is changed to std::string.
Maybe, you should also put the wxString to utf8 format at the last stage as:
didChangeEvent.text = edText.ToUTF8();
Sometimes, when a new editor get opened. (mostly happens when I use find declaration to open a new editor), there is a message shown in the right bottom corner of the C::B's main frame immediately after the editor opened, and it said this file is not parsed yet. I also believe this is a wrong event sequence handling issue.
-------------------- clangd_client/src/LSPclient/client.cpp --------------------
index c1d5d59..c6f8c22 100644
@@ -2649,7 +2649,7 @@ void ProcessLanguageClient::LSP_DidChange(cbEditor* pEd)
didChangeEvent.range = range;
}
- didChangeEvent.text = edText;
+ didChangeEvent.text = edText.ToStdString(wxConvUTF8);
std::vector<TextDocumentContentChangeEvent> tdcce{didChangeEvent};
DocumentUri docuri = DocumentUri(fileURI.c_str());
// **debugging**
Hi, Pecan, I think this patch is still needed to handle the wxString to char* convertion, the char* should be UTF-8 format.
This is against rev69.Code-------------------- clangd_client/src/LSPclient/client.cpp --------------------
index c1d5d59..c6f8c22 100644
@@ -2649,7 +2649,7 @@ void ProcessLanguageClient::LSP_DidChange(cbEditor* pEd)
didChangeEvent.range = range;
}
- didChangeEvent.text = edText;
+ didChangeEvent.text = edText.ToStdString(wxConvUTF8);
std::vector<TextDocumentContentChangeEvent> tdcce{didChangeEvent};
DocumentUri docuri = DocumentUri(fileURI.c_str());
// **debugging**
wxLogMessage("aaa", aaa);
wxLogMessage("bbb", aaa);
I see one bug, I'm not sure it is a clangd bug or our client plugin bug.
When I do code refactoring, I mean I want to rename a variable aaa to bbb.
If there is a line:QuotewxLogMessage("aaa", aaa);
Then I will get this:QuotewxLogMessage("bbb", aaa);
maybe, clangd does not give us the column information of a variable? It just tell use the line information?
I see one bug, I'm not sure it is a clangd bug or our client plugin bug.
When I do code refactoring, I mean I want to rename a variable aaa to bbb.
If there is a line:QuotewxLogMessage("aaa", aaa);
Then I will get this:QuotewxLogMessage("bbb", aaa);
maybe, clangd does not give us the column information of a variable? It just tell use the line information?
Do you mean that the unquoted aaa should have been changed to the unquoted bbb (the second parameter) ?
AddrPC Params
00007FFC87E084EB 00000158724B49E0 0000002690BFE4F0 00000000FFFF86AD clangd_client.dll!Parser::LSP_ParseSemanticTokens
00007FFC87E13403 00000158724B49E0 00000158771FF080 0000000000000000 clangd_client.dll!Parser::OnLSP_RequestedSemanticTokensResponse
00007FFC87DB64F1 000001586D6EB3F0 00000158771FF080 0000002690BFEED0 clangd_client.dll!ClgdCompletion::OnLSP_Event
00007FFC2F35398C 000001586CB04130 000001586D6EB3F0 00007FFC2A605B5E wxmsw315ud_gcc_custom.dll!wxAppConsoleBase::HandleEvent
00007FFC2F353A0D 000001586CB04130 000001586D6EB3F0 000001586D50E880 wxmsw315ud_gcc_custom.dll!wxAppConsoleBase::CallEventHandler
00007FFC2F42DBF4 000001586D50E8E0 000001586D6EB3F0 00000158771FF080 wxmsw315ud_gcc_custom.dll!wxEvtHandler::ProcessEventIfMatchesId
00007FFC2F42E90A 000001586D6EB3F0 00000158771FF080 00000158771FF080 wxmsw315ud_gcc_custom.dll!wxEvtHandler::SearchDynamicEventTable
00007FFC2F42E07A 000001586D6EB3F0 00000158771FF080 0000002690BFF0C0 wxmsw315ud_gcc_custom.dll!wxEvtHandler::TryHereOnly
00007FFC2FC31040 000001586D6EB3F0 00000158771FF080 0000015870E46080 wxmsw315ud_gcc_custom.dll!wxEvtHandler::TryBeforeAndHere
00007FFC2F42DE83 000001586D6EB3F0 00000158771FF080 000001586D6EB3F0 wxmsw315ud_gcc_custom.dll!wxEvtHandler::ProcessEvent
00007FFC2F42DF7F 000001587244F920 00000158771FF080 0000002690BFF120 wxmsw315ud_gcc_custom.dll!wxEvtHandler::DoTryChain
00007FFC2F42DF10 000001587244F920 00000158771FF080 000001586CAB5FB0 wxmsw315ud_gcc_custom.dll!wxEvtHandler::ProcessEventLocally
00007FFC2F42DE95 000001587244F920 00000158771FF080 00000158773507D0 wxmsw315ud_gcc_custom.dll!wxEvtHandler::ProcessEvent
00007FFC2F42DA98 000001587244F920 0000000000000000 000001586CB042F8 wxmsw315ud_gcc_custom.dll!wxEvtHandler::ProcessPendingEvents
00007FFC2F3535ED 000001586CB04130 00007FFC2F4FFA99 000001586CB04130 wxmsw315ud_gcc_custom.dll!wxAppConsoleBase::ProcessPendingEvents
00007FFC2F37666E 000001587479F1C0 0000000000000040 0000002690BFF380 wxmsw315ud_gcc_custom.dll!wxEventLoopManual::ProcessEvents
00007FFC2F37677D 000001587479F1C0 000001587479F1D4 000001587479F100 wxmsw315ud_gcc_custom.dll!wxEventLoopManual::DoRun
00007FFC2F376234 000001587479F1C0 000001586CB042F0 000001587479F1C0 wxmsw315ud_gcc_custom.dll!wxEventLoopBase::Run
00007FFC2F352E88 000001586CB04130 0000000000000055 000001586CAB5FB0 wxmsw315ud_gcc_custom.dll!wxAppConsoleBase::MainLoop
00007FFC2F352BB2 000001586CB04130 00007FFCDC9A03E0 00007FFCDC980000 wxmsw315ud_gcc_custom.dll!wxAppConsoleBase::OnRun
00007FFC2F59BA17 000001586CB04130 000001586CB00000 0000000000000000 wxmsw315ud_gcc_custom.dll!wxAppBase::OnRun
00007FF742BF5C8A 000001586CB04130 00007FFC3028D7B0 000001586B0CC050 codeblocks.exe!CodeBlocksApp::OnRun
00007FFC2F3A0FA2 00007FFC3028D7B0 000001586B0CC050 000001586CAAF898 wxmsw315ud_gcc_custom.dll!wxEntryReal
00007FFC2F436B60 00007FFC3028D7B0 000001586B0CC050 0000000000000000 wxmsw315ud_gcc_custom.dll!wxEntry
00007FFC2F436C45 00007FF742BF0000 0000000000000000 000001586B0C3987 wxmsw315ud_gcc_custom.dll!wxEntry
00007FF742BF2544 00007FF742BF0000 0000000000000000 000001586B0C3987 codeblocks.exe!WinMain
00007FF742BF13B1 0000000000000000 0000000000000000 0000000000000000 codeblocks.exe!__tmainCRTStartup
00007FF742BF14C6 0000000000000000 0000000000000000 0000000000000000 codeblocks.exe!WinMainCRTStartup
00007FFCDC997034 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk
00007FFCDD9E2651 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart
Hi, not quite sure what is happening, and i did not investigate, but i got a crash and this backtrace, just wanted to note it here:This looks like the crashes during CB shutdown or when closing a file while clangd sent a response to a previous request.CodeAddrPC Params
00007FFC87E084EB 00000158724B49E0 0000002690BFE4F0 00000000FFFF86AD clangd_client.dll!Parser::LSP_ParseSemanticTokens
00007FFC87E13403 00000158724B49E0 00000158771FF080 0000000000000000 clangd_client.dll!Parser::OnLSP_RequestedSemanticTokensResponse
00007FFC87DB64F1 000001586D6EB3F0 00000158771FF080 0000002690BFEED0 clangd_client.dll!ClgdCompletion::OnLSP_Event
00007FFC2F35398C 000001586CB04130 000001586D6EB3F0 00007FFC2A605B5E wxmsw315ud_gcc_custom.dll!wxAppConsoleBase::HandleEvent
00007FFC2F353A0D 000001586CB04130 000001586D6EB3F0 000001586D50E880 wxmsw315ud_gcc_custom.dll!wxAppConsoleBase::CallEventHandler
00007FFC2F42DBF4 000001586D50E8E0 000001586D6EB3F0 00000158771FF080 wxmsw315ud_gcc_custom.dll!wxEvtHandler::ProcessEventIfMatchesId
00007FFC2F42E90A 000001586D6EB3F0 00000158771FF080 00000158771FF080 wxmsw315ud_gcc_custom.dll!wxEvtHandler::SearchDynamicEventTable
00007FFC2F42E07A 000001586D6EB3F0 00000158771FF080 0000002690BFF0C0 wxmsw315ud_gcc_custom.dll!wxEvtHandler::TryHereOnly
00007FFC2FC31040 000001586D6EB3F0 00000158771FF080 0000015870E46080 wxmsw315ud_gcc_custom.dll!wxEvtHandler::TryBeforeAndHere
00007FFC2F42DE83 000001586D6EB3F0 00000158771FF080 000001586D6EB3F0 wxmsw315ud_gcc_custom.dll!wxEvtHandler::ProcessEvent
00007FFC2F42DF7F 000001587244F920 00000158771FF080 0000002690BFF120 wxmsw315ud_gcc_custom.dll!wxEvtHandler::DoTryChain
00007FFC2F42DF10 000001587244F920 00000158771FF080 000001586CAB5FB0 wxmsw315ud_gcc_custom.dll!wxEvtHandler::ProcessEventLocally
00007FFC2F42DE95 000001587244F920 00000158771FF080 00000158773507D0 wxmsw315ud_gcc_custom.dll!wxEvtHandler::ProcessEvent
00007FFC2F42DA98 000001587244F920 0000000000000000 000001586CB042F8 wxmsw315ud_gcc_custom.dll!wxEvtHandler::ProcessPendingEvents
00007FFC2F3535ED 000001586CB04130 00007FFC2F4FFA99 000001586CB04130 wxmsw315ud_gcc_custom.dll!wxAppConsoleBase::ProcessPendingEvents
00007FFC2F37666E 000001587479F1C0 0000000000000040 0000002690BFF380 wxmsw315ud_gcc_custom.dll!wxEventLoopManual::ProcessEvents
00007FFC2F37677D 000001587479F1C0 000001587479F1D4 000001587479F100 wxmsw315ud_gcc_custom.dll!wxEventLoopManual::DoRun
00007FFC2F376234 000001587479F1C0 000001586CB042F0 000001587479F1C0 wxmsw315ud_gcc_custom.dll!wxEventLoopBase::Run
00007FFC2F352E88 000001586CB04130 0000000000000055 000001586CAB5FB0 wxmsw315ud_gcc_custom.dll!wxAppConsoleBase::MainLoop
00007FFC2F352BB2 000001586CB04130 00007FFCDC9A03E0 00007FFCDC980000 wxmsw315ud_gcc_custom.dll!wxAppConsoleBase::OnRun
00007FFC2F59BA17 000001586CB04130 000001586CB00000 0000000000000000 wxmsw315ud_gcc_custom.dll!wxAppBase::OnRun
00007FF742BF5C8A 000001586CB04130 00007FFC3028D7B0 000001586B0CC050 codeblocks.exe!CodeBlocksApp::OnRun
00007FFC2F3A0FA2 00007FFC3028D7B0 000001586B0CC050 000001586CAAF898 wxmsw315ud_gcc_custom.dll!wxEntryReal
00007FFC2F436B60 00007FFC3028D7B0 000001586B0CC050 0000000000000000 wxmsw315ud_gcc_custom.dll!wxEntry
00007FFC2F436C45 00007FF742BF0000 0000000000000000 000001586B0C3987 wxmsw315ud_gcc_custom.dll!wxEntry
00007FF742BF2544 00007FF742BF0000 0000000000000000 000001586B0C3987 codeblocks.exe!WinMain
00007FF742BF13B1 0000000000000000 0000000000000000 0000000000000000 codeblocks.exe!__tmainCRTStartup
00007FF742BF14C6 0000000000000000 0000000000000000 0000000000000000 codeblocks.exe!WinMainCRTStartup
00007FFCDC997034 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk
00007FFCDD9E2651 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart
Fixed rev 70I see one bug, I'm not sure it is a clangd bug or our client plugin bug.
When I do code refactoring, I mean I want to rename a variable aaa to bbb.
If there is a line:QuotewxLogMessage("aaa", aaa);
Then I will get this:QuotewxLogMessage("bbb", aaa);
maybe, clangd does not give us the column information of a variable? It just tell use the line information?
Do you mean that the unquoted aaa should have been changed to the unquoted bbb (the second parameter) ?
Yes.
@BlueHazzard, maybe you can check the log files in your system Temp folder to see what content were sent from the clangd.It could be this two logs, but i am not 100% sure:
21:58:21.731 Project: Addr2LineUI wx3.1.x (64 bit): codeblocksdir\src\tools\Addr2LineUI\Addr2LineUI_wx31_64.cbp
21:58:21.731 SystemPath: C:\msys64\mingw64\bin;C:\msys64\mingw64\bin\bin;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\tools;C:\Program Files\WireGuard;C;C:\Program Files\TortoiseSVN\bin;C:\Program Files\AMD\AMDuProf\bin;C:\Users\eberh\AppData\Local\Microsoft\WindowsApps
21:58:21.733 <<< Initialize(): codeblocksdir/src/tools/Addr2LineUI
21:58:21.734 <<< Content-Length: 1202
{"id":"initialize","jsonrpc":"2.0","method":"initialize","params":{"capabilities":{"offsetEncoding":["utf-8"],"textDocument":{"codeAction":{"codeActionLiteralSupport":true},"completion":{"completionItem":{"deprecatedSupport":true,"snippetSupport":true},"completionItemKind":{"valueSet":[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25]},"editsNearCursor":true},"documentSymbol":{"hierarchicalDocumentSymbolSupport":true},"hover":{"contentFormat":["plaintext"]},"publishDiagnostics":{"categorySupport":true,"codeActionsInline":true,"relatedInformation":true},"semanticTokens":{"dynamicRegistration":true},"signatureHelp":{"signatureInformation":{"parameterInformation":{"labelOffsetSupport":true}}}},"workspace":{"applyEdit":false,"symbol":{"symbolKind":{"valueSet":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]}},"workspaceEdit":{"documentChanges":false}}},"initializationOptions":{"clangdFileStatus":false,"compilationDatabasePath":null,"configSettings":{"compilationDatabaseChanges":{}},"fallbackFlags":[]},"processId":21764,"rootPath":null,"rootUri":"file:///codeblocksdir/src/tools/Addr2LineUI"}}
21:58:21.990 >>> readJson() len:1873:
{"id":"initialize","jsonrpc":"2.0","result":{"capabilities":{"astProvider":true,"callHierarchyProvider":true,"clangdInlayHintsProvider":true,"codeActionProvider":true,"compilationDatabase":{"automaticReload":true},"completionProvider":{"allCommitCharacters":[" ","\t","(",")","[","]","{","}","<",">",":",";",",","+","-","/","*","%","^","&","#","?",".","=","\"","'","|"],"resolveProvider":false,"triggerCharacters":[".","<",">",":","\"","/","*"]},"declarationProvider":true,"definitionProvider":true,"documentFormattingProvider":true,"documentHighlightProvider":true,"documentLinkProvider":{"resolveProvider":false},"documentOnTypeFormattingProvider":{"firstTriggerCharacter":"\n","moreTriggerCharacter":[]},"documentRangeFormattingProvider":true,"documentSymbolProvider":true,"executeCommandProvider":{"commands":["clangd.applyFix","clangd.applyTweak"]},"hoverProvider":true,"implementationProvider":true,"memoryUsageProvider":true,"referencesProvider":true,"renameProvider":true,"selectionRangeProvider":true,"semanticTokensProvider":{"full":{"delta":true},"legend":{"tokenModifiers":["declaration","deprecated","deduced","readonly","static","abstract","virtual","dependentName","defaultLibrary","usedAsMutableReference","functionScope","classScope","fileScope","globalScope"],"tokenTypes":["variable","variable","parameter","function","method","function","property","variable","class","interface","enum","enumMember","type","type","unknown","namespace","typeParameter","concept","type","macro","comment"]},"range":false},"signatureHelpProvider":{"triggerCharacters":["(",")","{","}","<",">",","]},"textDocumentSync":{"change":2,"openClose":true,"save":true},"typeDefinitionProvider":true,"typeHierarchyProvider":true,"workspaceSymbolProvider":true},"offsetEncoding":"utf-8","serverInfo":{"name":"clangd","version":"clangd version 14.0.4 windows x86_64-w64-windows-gnu"}}}
Project: Addr2LineUI wx3.1.x (64 bit): codeblocksdir\src\tools\Addr2LineUI\Addr2LineUI_wx31_64.cbp
SystemPath: C:\msys64\mingw64\bin;C:\msys64\mingw64\bin\bin;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\tools;C:\Program Files\WireGuard;C;C:\Program Files\TortoiseSVN\bin;C:\Program Files\AMD\AMDuProf\bin;C:\Users\eberh\AppData\Local\Microsoft\WindowsApps
I[21:58:21.827] clangd version 14.0.4
I[21:58:21.828] Features: windows
I[21:58:21.828] PID: 26712
I[21:58:21.828] Working directory: codeblocksdir/src/tools/Addr2LineUI
I[21:58:21.828] argv[0]: C:\msys64\mingw64\bin\clangd.exe
I[21:58:21.828] argv[1]: --log=verbose
I[21:58:21.828] argv[2]: --query-driver=C:\msys64\mingw64\bin\**\x*
I[21:58:21.828] argv[3]: -j=8
I[21:58:21.828] argv[4]: --limit-results=20
I[21:58:21.828] argv[5]: --resource-dir=C:\msys64\mingw64\lib\clang\14.0.4
V[21:58:21.830] User config file is C:/Users/eberh/AppData/Local/clangd/config.yaml
I[21:58:21.830] Starting LSP over stdin/stdout
V[21:58:21.830] <<< {"id":"initialize","jsonrpc":"2.0","method":"initialize","params":{"capabilities":{"offsetEncoding":["utf-8"],"textDocument":{"codeAction":{"codeActionLiteralSupport":true},"completion":{"completionItem":{"deprecatedSupport":true,"snippetSupport":true},"completionItemKind":{"valueSet":[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25]},"editsNearCursor":true},"documentSymbol":{"hierarchicalDocumentSymbolSupport":true},"hover":{"contentFormat":["plaintext"]},"publishDiagnostics":{"categorySupport":true,"codeActionsInline":true,"relatedInformation":true},"semanticTokens":{"dynamicRegistration":true},"signatureHelp":{"signatureInformation":{"parameterInformation":{"labelOffsetSupport":true}}}},"workspace":{"applyEdit":false,"symbol":{"symbolKind":{"valueSet":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]}},"workspaceEdit":{"documentChanges":false}}},"initializationOptions":{"clangdFileStatus":false,"compilationDatabasePath":null,"configSettings":{"compilationDatabaseChanges":{}},"fallbackFlags":[]},"processId":21764,"rootPath":null,"rootUri":"file:///codeblocksdir/src/tools/Addr2LineUI"}}
I[21:58:21.830] <-- initialize("initialize")
I[21:58:21.851] --> reply:initialize("initialize") 21 ms
V[21:58:21.851] >>> {"id":"initialize","jsonrpc":"2.0","result":{"capabilities":{"astProvider":true,"callHierarchyProvider":true,"clangdInlayHintsProvider":true,"codeActionProvider":true,"compilationDatabase":{"automaticReload":true},"completionProvider":{"allCommitCharacters":[" ","\t","(",")","[","]","{","}","<",">",":",";",",","+","-","/","*","%","^","&","#","?",".","=","\"","'","|"],"resolveProvider":false,"triggerCharacters":[".","<",">",":","\"","/","*"]},"declarationProvider":true,"definitionProvider":true,"documentFormattingProvider":true,"documentHighlightProvider":true,"documentLinkProvider":{"resolveProvider":false},"documentOnTypeFormattingProvider":{"firstTriggerCharacter":"\n","moreTriggerCharacter":[]},"documentRangeFormattingProvider":true,"documentSymbolProvider":true,"executeCommandProvider":{"commands":["clangd.applyFix","clangd.applyTweak"]},"hoverProvider":true,"implementationProvider":true,"memoryUsageProvider":true,"referencesProvider":true,"renameProvider":true,"selectionRangeProvider":true,"semanticTokensProvider":{"full":{"delta":true},"legend":{"tokenModifiers":["declaration","deprecated","deduced","readonly","static","abstract","virtual","dependentName","defaultLibrary","usedAsMutableReference","functionScope","classScope","fileScope","globalScope"],"tokenTypes":["variable","variable","parameter","function","method","function","property","variable","class","interface","enum","enumMember","type","type","unknown","namespace","typeParameter","concept","type","macro","comment"]},"range":false},"signatureHelpProvider":{"triggerCharacters":["(",")","{","}","<",">",","]},"textDocumentSync":{"change":2,"openClose":true,"save":true},"typeDefinitionProvider":true,"typeHierarchyProvider":true,"workspaceSymbolProvider":true},"offsetEncoding":"utf-8","serverInfo":{"name":"clangd","version":"clangd version 14.0.4 windows x86_64-w64-windows-gnu"}}}
@BlueHazzard, maybe you can check the log files in your system Temp folder to see what content were sent from the clangd.
The crash is still happening with r70,
i can reproduce it now:
1) Open codeblocks
2) Open a project with some code (i used the clang_cc project)
3) Hit recompile as fast as you can after project load, and the cc parser is not finished. compiling will start and in the middle -> crash
backtrace and log content is the same as in my previous posts
-------------------
Error occurred on Sunday, July 31, 2022 at 11:00:29.
CodeBlocks.exe caused an Access Violation at location 00007FFFFAAAC2DC in module codeblocks.dll Reading from location FFFFFFFFFFFFFFFF.
AddrPC Params
00007FFFFAAAC2DC 00000120EBD30BE0 0000001A76BFED50 00000000000005E9 codeblocks.dll!wxPostEvent+0x9c [D:/Andrew_Development/Libraries/wxWidgets-3.2.0_win64/include/wx/event.h @ 4169]
4167: wxCHECK_RET( dest, "need an object to post event to" );
4168:
> 4169: dest->AddPendingEvent(event);
4170: }
4171:
00007FFFFA8BD86B 00000120F3EED750 00007FFF000049E8 0000000000000000 codeblocks.dll!PipedProcess::OnTerminate+0xd7 [D:/Andrew_Development/Work_Installers/CodeBLocks_Private_Experimental_GCC/src/sdk/pipedprocess.cpp @ 235]
233: event.SetInt(status);
234: event.SetX(m_Index);
> 235: wxPostEvent(m_Parent, event);
236:
237: if (m_pvThis)
00007FFFC2B555A6 00000000002309D0 0000000000002B10 0000000000000000 wxmsw32ud_gcc_cb.dll!wxExecuteWindowCbk+0xaf [D:/Andrew_Development/Libraries/wxWidgets-3.2.0_win64/build/msw/../../src/msw/utilsexc.cpp @ 341]
339: if ( data->handler )
340: {
> 341: data->handler->OnTerminate((int)data->dwProcessId,
342: (int)data->dwExitCode);
343: }
00007FF848E3E858 0000001A76BFF1E0 00007FFFC2B554F7 00000000002309D0 USER32.dll!UserCallWinProcCheckWow+0x2f8
00007FF848E3E3DC 0000000000000000 0000000000000000 0000000000000000 USER32.dll!DispatchClientMessage+0x9c
00007FF848E50BC3 0000000000000000 0000000000000000 00000000000083AE USER32.dll!__fnDWORD+0x33
00007FF849CF0D74 00007FF848E3A5C3 0000000000000000 0000000000000000 ntdll.dll!KiUserCallbackDispatch+0x24
00007FF847641064 0000000000000000 0000000000000000 0000000000000000 win32u.dll!NtUserPeekMessage+0x14
00007FF848E3A5C3 0000000000000000 00000120E8FCC7E0 0000000000000000 USER32.dll!_PeekMessage+0x43
00007FF848E3A523 00000120EA4331A8 0000001A76BFF440 0000000000000038 USER32.dll!PeekMessageW+0x143
00007FFFC2B37CAF 00000120EF9E2370 00000120EF9E2370 0000001A76BFF490 wxmsw32ud_gcc_cb.dll!wxMSWEventLoopBase::Pending+0x35 [D:/Andrew_Development/Libraries/wxWidgets-3.2.0_win64/build/msw/../../src/msw/evtloopconsole.cpp @ 62]
60: {
61: MSG msg;
> 62: return ::PeekMessage(&msg, 0, 0, 0, PM_NOREMOVE) != 0;
63: }
64:
00007FFFC2AA6E6C 00000120EF9E2370 00000120EF9E2384 0000000000000000 wxmsw32ud_gcc_cb.dll!wxEventLoopManual::DoRun+0x52 [D:/Andrew_Development/Libraries/wxWidgets-3.2.0_win64/build/msw/../../src/common/evtloopcmn.cpp @ 276]
274: // for them too
275: while ( !m_shouldExit
> 276: && !Pending()
277: && !(wxTheApp && wxTheApp->HasPendingEvents())
278: && ProcessIdle() )
00007FFFC2AA6973 00000120EF9E2370 00000120EA47B650 00000120EF9E2370 wxmsw32ud_gcc_cb.dll!wxEventLoopBase::Run+0xf7 [D:/Andrew_Development/Libraries/wxWidgets-3.2.0_win64/build/msw/../../src/common/evtloopcmn.cpp @ 87]
85:
86: // Finally really run the loop.
> 87: return DoRun();
88: }
89:
00007FFFC2A82E85 00000120EA47B490 0000000000000038 0000000000000000 wxmsw32ud_gcc_cb.dll!wxAppConsoleBase::MainLoop+0x93 [D:/Andrew_Development/Libraries/wxWidgets-3.2.0_win64/build/msw/../../src/common/appbase.cpp @ 381]
379: wxTheApp->OnLaunched();
380:
> 381: return m_mainLoop ? m_mainLoop->Run() : -1;
382: }
383:
00007FFFC2A82BBD 00000120EA47B490 00007FF8490703E0 00007FF849050000 wxmsw32ud_gcc_cb.dll!wxAppConsoleBase::OnRun+0x25 [D:/Andrew_Development/Libraries/wxWidgets-3.2.0_win64/build/msw/../../src/common/appbase.cpp @ 303]
301: int wxAppConsoleBase::OnRun()
302: {
> 303: return MainLoop();
304: }
305:
00007FFFC2CDDF7B 00000120EA47B490 00007FF849C75BA1 0000000000000000 wxmsw32ud_gcc_cb.dll!wxAppBase::OnRun+0x35 [D:/Andrew_Development/Libraries/wxWidgets-3.2.0_win64/build/msw/../../src/common/appcmn.cpp @ 334]
332: //else: it has been changed, assume the user knows what he is doing
333:
> 334: return wxAppConsole::OnRun();
335: }
336:
00007FF62FE68EBC 00000120EA47B490 00007FFFC3ADA7B0 00000120E8A1EAF0 CodeBlocks.exe!CodeBlocksApp::OnRun+0x30 [D:/Andrew_Development/Work_Installers/CodeBLocks_Private_Experimental_GCC/src/src/app.cpp @ 1070]
1068: try
1069: {
> 1070: int retval = wxApp::OnRun();
1071: // wx 2.6.3 docs says that OnRun() function's return value is used as exit code
1072: return m_Batch ? m_BatchExitCode : retval;
00007FFFC2AD1B32 00007FFFC3ADA7B0 00000120E8A1EAF0 00000120EA4692F0 wxmsw32ud_gcc_cb.dll!wxEntryReal+0xaa [D:/Andrew_Development/Libraries/wxWidgets-3.2.0_win64/build/msw/../../src/common/init.cpp @ 503]
501:
502: // app execution
> 503: return wxTheApp->OnRun();
504: }
505: wxCATCH_ALL( wxTheApp->OnUnhandledException(); return -1; )
00007FFFC2B69390 00007FFFC3ADA7B0 00000120E8A1EAF0 0000000000000000 wxmsw32ud_gcc_cb.dll!wxEntry+0x20 [D:/Andrew_Development/Libraries/wxWidgets-3.2.0_win64/build/msw/../../src/msw/main.cpp @ 184]
182: int wxEntry(int& argc, wxChar **argv)
183: {
> 184: return wxEntryReal(argc, argv);
185: }
186:
00007FFFC2B6947A 00007FF62FE60000 0000000000000000 00000120E8A13C5A wxmsw32ud_gcc_cb.dll!wxEntry+0x4e [D:/Andrew_Development/Libraries/wxWidgets-3.2.0_win64/build/msw/../../src/msw/main.cpp @ 296]
294: return -1;
295:
> 296: return wxEntry(wxArgs.argc, wxArgs.argv);
297: }
298:
00007FF62FE6257D 00007FF62FE60000 0000000000000000 00000120E8A13C5A CodeBlocks.exe!WinMain+0x3a [D:/Andrew_Development/Work_Installers/CodeBLocks_Private_Experimental_GCC/src/src/app.cpp @ 339]
337: } // namespace
338:
> 339: IMPLEMENT_APP(CodeBlocksApp) // TODO: This gives a "redundant declaration" warning, though I think it's false. Dig through macro and check.
340:
341: BEGIN_EVENT_TABLE(CodeBlocksApp, wxApp)
00007FF62FE613AE 0000000000000000 0000000000000000 0000000000000000 CodeBlocks.exe!__tmainCRTStartup+0x22e [C:/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c @ 329]
00007FF62FE614E6 0000000000000000 0000000000000000 0000000000000000 CodeBlocks.exe!mainCRTStartup+0x16 [C:/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c @ 206]
00007FF849067034 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk+0x14
00007FF849CA2651 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart+0x21
Windows 10.0.19044
DrMingw 0.9.5
Just before it crashed were you editing or had some other app (not C::B) in focus?
AddrPC Params
0000000070CB7861 000000002D1DC710 000000000083EDDC 000000000083EDD8 codeblocks.dll!cbThreadPool::Done
0000000070CB7497 000000000083EE30 000000002D1DC710 000000002D96A1F0 codeblocks.dll!cbThreadPool::Done
00000000709830CA 000000000B03A350 000000000083F140 000000002F8D3F80 codeblocks.dll!CCManager::OnPopupScroll
Probably because of recent changes in C::B sdk, clangd_client does not compile when using wxWidgets 3.2.1 (probably >= 3.1.6)
Error in client.cpp, line 3672 : CodeBlocksLogEvent waits for a wxBitmapBundle*, but logbmp is a wxBitmap*
const int uiSize = Manager::Get()->GetImageSize(Manager::UIComponent::InfoPaneNotebooks);
const int uiScaleFactor = Manager::Get()->GetUIScaleFactor(Manager::UIComponent::InfoPaneNotebooks);
const wxString imgFile = ConfigManager::GetDataFolder()
+ wxString::Format(_T("/resources.zip#zip:/images/%dx%d/filefind.png"),
uiSize, uiSize);
wxBitmap* logbmp = new wxBitmap(cbLoadBitmapScaled(imgFile, wxBITMAP_TYPE_PNG, uiScaleFactor));
const int uiSize = Manager::Get()->GetImageSize(Manager::UIComponent::InfoPaneNotebooks);
wxString prefix(ConfigManager::GetDataFolder()+"/resources.zip#zip:/images/");
#if wxCHECK_VERSION(3, 1, 6)
const double uiScaleFactor = Manager::Get()->GetUIScaleFactor(Manager::UIComponent::InfoPaneNotebooks);
wxBitmapBundle* logbmp = new wxBitmapBundle(cbLoadBitmapBundle(prefix, "filefind.png", wxRound(uiSize/uiScaleFactor), wxBITMAP_TYPE_PNG));
#else
prefix << wxString::Format("%dx%d/", uiSize, uiSize);
wxBitmap* logbmp = new wxBitmap(cbLoadBitmap(prefix+"filefind.png", wxBITMAP_TYPE_PNG));
#endif
@ MaxGaspa
Until I can find the cause of the crash, you can disable Settings/Editor/GeneralSetting/Documentation popup.
This should eliminate the stall/crash. If It does not, let me know.
Thanks
else if (m_pAutocompPopup && m_pAutocompPopup->GetScreenRect().Contains(pos))
1) The HtmlDocumentationPopup gets stuck showing and cannot be closed.
2) The user did a double-click to select from the AutocompPopup, the HtmlDocumentationPopup got left showing and CB is frozen (and may crash).
3) The AutocompPopup and the HtmlPopup are showing, the user unfocused CB then re-focused CB and CB is frozen and must be killed.
4) The user has unChecked Documentation popup in options and now AutocompPopups cannot be scrolled.
5) The AutocompPopup only is stuck showing and cannot be closed.
std::map<cbEditor*,bool> m_EdAutoCompMouseTraps;
m_EdAutoCompMouseTraps[ed] = true;
About the ccManagerMouseTrap220915-1.patch file.
I'm not sure, but this variableCodestd::map<cbEditor*,bool> m_EdAutoCompMouseTraps;
The bool value is always "true"? Since I see the only code here is:Codem_EdAutoCompMouseTraps[ed] = true;
Also, is the code Windows related? If yes, I think the "#ifdef __WXMSW__" should also be placed in the header file around this member variable declaration.
#ifdef __WXMSW__
/** a handle to the autocomplete list window created by (wx)scintilla, needed under Windows
* to determine its dimensions (so the scroll event can be sent to it, if relevant)
*/
wxListView* m_pAutocompPopup;
/**
* List of editors holding an event connect to popup mouse scroll event
* for AutoCompPopup and html Documentation popup
*/
std::map<cbEditor*,bool> m_EdAutoCompMouseTraps;
#endif // __WXMSW__
m_EdAutoCompMouseTraps[ed] = true;
m_EdAutoCompMouseTraps.erase(m_pLastEditor);
Is there a better method for inserting a entry into a map?
I'm not fully understand the code logic, but do you really need a map? When a key is added, it's value is always "true".
I mean a std::set<cbEditor*> is better than std::map<cbEditor*,bool> ?
// ----------------------------------------------------------------------------
void Parser::OnLSP_RequestedSemanticTokensResponse(wxCommandEvent& event) //(ph 2021/03/12)
// ----------------------------------------------------------------------------
{
if (GetIsShuttingDown()) return;
// This is a callback after requesting textDocument/Symbol (request done at end of OnLSP_RequestedSymbolsResponse() )
// Currently, we allow SemanticTokens for the BuiltinActiveEditor only,
// ----------------------------------------------------------------------------
/// GetClientData() contains ptr to json object
/// DONT free it! The return to OnLSP_Event() will free it as a unique_ptr
// ----------------------------------------------------------------------------
json* pJson = (json*)event.GetClientData();
wxString idStr = event.GetString();
wxString URI = idStr.AfterFirst(STX);
if (URI.Contains(STX))
URI = URI.BeforeFirst(STX); //filename
wxString uriFilename = fileUtils.FilePathFromURI(URI); //(ph 2021/12/21)
cbEditor* pEditor = nullptr;
cbProject* pProject = nullptr;
EditorManager* pEdMgr = Manager::Get()->GetEditorManager();
EditorBase* pEdBase = pEdMgr->IsOpen(uriFilename);
if (pEdBase)
{
pEditor = pEdMgr->GetBuiltinActiveEditor();
if (not pEditor or (pEditor->GetFilename() != uriFilename))
return;
ProjectFile* pProjectFile = pEditor->GetProjectFile();
if (pProjectFile) pProject = pProjectFile->GetParentProject();
if ( (not pProjectFile) or (not pProject) ) return;
ParserBase* pParser = GetParseManager()->GetParserByProject(pProject);
if (not pParser)
return;
}
else return;
if (not pProject) pProject = Manager::Get()->GetProjectManager()->GetActiveProject();
ProcessLanguageClient* pClient = GetLSPClient();
// Queue the the json data to OnLSP_ParseDocumentSymbols() event, passing it the json pointer
// The json data will be placed in a queue to be processed during OnIdle() events. //(ph 2021/09/11)
wxCommandEvent symEvent(wxEVT_COMMAND_MENU_SELECTED, XRCID("textDocument/semanticTokens"));
symEvent.SetString(uriFilename);
symEvent.SetClientData(pJson);
LSP_ParseSemanticTokens(symEvent); //Call directly
// ----------------------------------------------------------------------------
Token* LSP_SymbolsParser::DoHandleClass(EClassType ct, int lineNumber, int lastLineNumber, int endCol) //(ph 2021/05/15)
// ----------------------------------------------------------------------------
{
// need to force the tokenizer _not_ skip anything
// as we 're manually parsing class decls
// don't forget to reset that if you add any early exit condition!
TokenizerState oldState = m_Tokenizer.GetState();
m_Tokenizer.SetState(tsNormal);
I have a question:
LSP_ParseSemanticTokens(), what does this function used for?
[Window Title]
Assert(non fatal)
[Content]
Trying to DoParse recursion in DoHandleClass():2028
[OK]
Quote1) The HtmlDocumentationPopup gets stuck showing and cannot be closed.
2) The user did a double-click to select from the AutocompPopup, the HtmlDocumentationPopup got left showing and CB is frozen (and may crash).
3) The AutocompPopup and the HtmlPopup are showing, the user unfocused CB then re-focused CB and CB is frozen and must be killed.
4) The user has unChecked Documentation popup in options and now AutocompPopups cannot be scrolled.
5) The AutocompPopup only is stuck showing and cannot be closed.
Hi, Pecan, good work! I see issue5 many times randomly in my daily work, but it is hard to reproduce, I even don't know how to reproduce this issue. The popup window shown on top of every application, and even CB is not focused, the popup window is still showing. What I have to do is kill the C::B process from the task manager.
Hope your fix will solve those issues, thanks!
I see another issus is that not the full tooltip window is shown, see the image shot as attachment.
I see only a very small portion of the tooltip window is shown, and the right side of the window is hidden.
I'm using the C::B svn rev12908, and the latest clangd_client plugin rev78, but I see the issue "popup(tooltip) window shown on top of every application" still happens. :(
I'm using the C::B svn rev12908, and the latest clangd_client plugin rev78, but I see the issue "popup(tooltip) window shown on top of every application" still happens. :(
Do you mean the popup when you hover over a function name or function parameters ?
I see another issus is that not the full tooltip window is shown, see the image shot as attachment.
I see only a very small portion of the tooltip window is shown, and the right side of the window is hidden.
This is not a clangd_client problem. Only ccManager has control over the popup(s) appearances.
Change Settings/Editor/OtherEditorSettings(tab)/Technology:(choice list) to Direct write.
I see another issus is that not the full tooltip window is shown, see the image shot as attachment.
I see only a very small portion of the tooltip window is shown, and the right side of the window is hidden.
This is not a clangd_client problem. Only ccManager has control over the popup(s) appearances.
Change Settings/Editor/OtherEditorSettings(tab)/Technology:(choice list) to Direct write.
This does not solve the issue.
The issue happens in both options, whether it is the Direct2D or the default option.
Thanks.I see another issus is that not the full tooltip window is shown, see the image shot as attachment.
I see only a very small portion of the tooltip window is shown, and the right side of the window is hidden.
This is not a clangd_client problem. Only ccManager has control over the popup(s) appearances.
Change Settings/Editor/OtherEditorSettings(tab)/Technology:(choice list) to Direct write.
This does not solve the issue.
The issue happens in both options, whether it is the Direct2D or the default option.
I'll enter the problem into the clangd_client ticket system and investigate.
Thanks for reporting.
/** Structure representing an individual calltip with an optional highlighted range */
struct CCCallTip
// ----------------------------------------------------------------------------
// SignatureHelp event
// ----------------------------------------------------------------------------
else if ( evtString.StartsWith("textDocument/signatureHelp"))
{
Parser* pParser = (Parser*)GetParseManager()->GetParserByProject(pProject);
pParser->OnLSP_SignatureHelpResponse(event, m_SignatureTokens, m_HoverLastPosition);
}
This does not solve the issue.
This does not solve the issue.
I had the same problem but setting Direct Write fixed it completely, I'm no longer observing the issue in several days of use....I'm using "Source Code Pro" font and the option "LCD Optimized" but my guess is that the font and optimization doesn't matter
(win7 pro and Win10 Entreprise, latest nightly and latest clangd plugin)
This does not solve the issue.
I had the same problem but setting Direct Write fixed it completely, I'm no longer observing the issue in several days of use....I'm using "Source Code Pro" font and the option "LCD Optimized" but my guess is that the font and optimization doesn't matter
(win7 pro and Win10 Entreprise, latest nightly and latest clangd plugin)
Hi, thanks for the reply.
I just tried it again. I have enabled the Direct Write, and I changed to many kinds of fonts, and the issue still happens.
This also happens when I disable the Direct Write in the Editor option.
The interesting thing is, when the first time I hover the variable, I got this black rectangle(see the attachment). I just tried several times, and the tip messages are all black rectangles, and it start to show a white rectangle about 5 or 6 times later.
Please note that not the all tooltip window has such issue, it only happens on a specify member variables. I guess that the text try to shown in the tip window masses the tip window, but not the other variables' tip message.
What is the variable(s) or name(s) that cause the issue. So that I can try to catch it in the debugger.
Can you give me some code that causes the issue.
So far, I have not been able to re-create the problem.
#include <iostream>
#include <fstream>
using namespace std;
// this file is not used any more?
// std::ofstream txtFile; ///< txt信息
std::ofstream m_TcpFile; ///< TCP接收的数据
int main()
{
cout << "Hello world!" << endl;
return 0;
}
///< TCP接收的数据
int m_TcpFile; ///< TCP接收的数据
int main()
{
return 0;
}
size_t resultCount = pJson->at("result").size();
if (not resultCount) return;
// Nothing for ShowCalltip is ever in the signature array //(ph 2021/11/1)
// Show Tootip vs ShowCalltip is so damn confusing !!!
// **debugging**std::string dumpit = pJson->dump();
size_t signatureCount = pJson->at("result").at("signatures").size();
if (not signatureCount) return;
json signatures = pJson->at("result").at("signatures");
for (size_t labelndx=0; labelndx<signatureCount && labelndx<10; ++labelndx)
{
wxString labelValue = signatures[labelndx].at("label").get<std::string>();
v_SignatureTokens.push_back(cbCodeCompletionPlugin::CCCallTip(labelValue));
}
wxString labelValue = signatures[labelndx].at("label").get<std::string>();
From 8523dd2bd9a58d1780c3d2efe9459f7e5fccfb41 Mon Sep 17 00:00:00 2001
From: hide<hide@hide.hide>
Date: Fri, 30 Sep 2022 15:11:28 +0800
Subject: fix the wrong tip code when Chinese comment is used
diff --git a/clangd_client/src/codecompletion/parser/parser.cpp b/clangd_client/src/codecompletion/parser/parser.cpp
index 2b9c5ea..3ddde25 100644
--- a/clangd_client/src/codecompletion/parser/parser.cpp
+++ b/clangd_client/src/codecompletion/parser/parser.cpp
@@ -2546,7 +2546,8 @@ void Parser::OnLSP_HoverResponse(wxCommandEvent& event, std::vector<ClgdCCToken>
if (not valueItemsCount) return;
json contents = pJson->at("result").at("contents");
- wxString contentsValue = contents.at("value").get<std::string>();
+ std::string contentsValueStdString = contents.at("value").get<std::string>();
+ wxString contentsValue(contentsValueStdString.c_str(), wxConvUTF8);
// Example Hover contents: L"instance-method HelloWxWorldFrame::OnAbout\n\nType: void\nParameters:\n- wxCommandEvent & event\n\n// In HelloWxWorldFrame\nprivate: void HelloWxWorldFrame::OnAbout(wxCommandEvent &event)"
// get string array of hover info separated at /n chars.
@@ -2670,7 +2671,8 @@ void Parser::OnLSP_SignatureHelpResponse(wxCommandEvent& event, std::vector<cbCo
json signatures = pJson->at("result").at("signatures");
for (size_t labelndx=0; labelndx<signatureCount && labelndx<10; ++labelndx)
{
- wxString labelValue = signatures[labelndx].at("label").get<std::string>();
+ std::string labelValueStdString = signatures[labelndx].at("label").get<std::string>();
+ wxString labelValue(labelValueStdString.c_str(), wxConvUTF8);
v_SignatureTokens.push_back(cbCodeCompletionPlugin::CCCallTip(labelValue));
}
wxString contentsValue = contents.at("value").get<std::string>();
std::string contentsValueStdString = contents.at("value").get<std::string>();
wxString contentsValue(contentsValueStdString.c_str(), wxConvUTF8);
Since i have seen quite some string encoding related issues in this thread and many try-and-error attempts to solve them, i want to add my two cents to these issues.
Never do this:CodewxString contentsValue = contents.at("value").get<std::string>();
This converts the std::string into a wxString using the currently set C++ locale. A locale set in CodeBlocks. But this std::string does not come from CodeBlocks. Also, std::string has, at least on Windows, no support for UTF-8. However, this doesn't stop anyone from putting UTF-8 into such a string. As long as you don't use methods that depend on the locale, this is fine. The code snippet above does depend on the locale.
Now these two lines:Codestd::string contentsValueStdString = contents.at("value").get<std::string>();
wxString contentsValue(contentsValueStdString.c_str(), wxConvUTF8);
These lines manually convert the std::string to a wxString by telling the wxString object that the std::string does contain UTF-8. Since the user post says this does fix the issue, apparently there is UTF-8 inside that std::string.
I suggest you figure out what encoding Clang does use and then check your code if you rely anywhere else on such automatic conversions. Also, wxWidgets offers the build option wxNO_UNSAFE_WXSTRING_CONV to disable such implicit conversions, but i am not sure if this does also work for std::string, they mention only C-Strings.
Since i have seen quite some string encoding related issues in this thread and many try-and-error attempts to solve them, i want to add my two cents to these issues.
Never do this:CodewxString contentsValue = contents.at("value").get<std::string>();
This converts the std::string into a wxString using the currently set C++ locale. A locale set in CodeBlocks. But this std::string does not come from CodeBlocks. Also, std::string has, at least on Windows, no support for UTF-8. However, this doesn't stop anyone from putting UTF-8 into such a string. As long as you don't use methods that depend on the locale, this is fine. The code snippet above does depend on the locale.
Now these two lines:Codestd::string contentsValueStdString = contents.at("value").get<std::string>();
wxString contentsValue(contentsValueStdString.c_str(), wxConvUTF8);
These lines manually convert the std::string to a wxString by telling the wxString object that the std::string does contain UTF-8. Since the user post says this does fix the issue, apparently there is UTF-8 inside that std::string.
I suggest you figure out what encoding Clang does use and then check your code if you rely anywhere else on such automatic conversions. Also, wxWidgets offers the build option wxNO_UNSAFE_WXSTRING_CONV to disable such implicit conversions, but i am not sure if this does also work for std::string, they mention only C-Strings.
Hi, sodev, thanks for the advice.
If I remember correctly, the clangd_client use the UTF-8 format for it's input source. Normally I use UTF-8 for my source code, but my system(Windows) locale is not UTF-8.
I see that clangd's document: Protocol extensions UTF-8 offsets (https://clangd.llvm.org/extensions.html#utf-8-offsets)
It said it can support UTF-8.
OK, I think I have fixed this issue by using such patch:CodeFrom 8523dd2bd9a58d1780c3d2efe9459f7e5fccfb41 Mon Sep 17 00:00:00 2001
From: hide<hide@hide.hide>
Date: Fri, 30 Sep 2022 15:11:28 +0800
Subject: fix the wrong tip code when Chinese comment is used
diff --git a/clangd_client/src/codecompletion/parser/parser.cpp b/clangd_client/src/codecompletion/parser/parser.cpp
index 2b9c5ea..3ddde25 100644
--- a/clangd_client/src/codecompletion/parser/parser.cpp
+++ b/clangd_client/src/codecompletion/parser/parser.cpp
@@ -2546,7 +2546,8 @@ void Parser::OnLSP_HoverResponse(wxCommandEvent& event, std::vector<ClgdCCToken>
if (not valueItemsCount) return;
json contents = pJson->at("result").at("contents");
- wxString contentsValue = contents.at("value").get<std::string>();
+ std::string contentsValueStdString = contents.at("value").get<std::string>();
+ wxString contentsValue(contentsValueStdString.c_str(), wxConvUTF8);
// Example Hover contents: L"instance-method HelloWxWorldFrame::OnAbout\n\nType: void\nParameters:\n- wxCommandEvent & event\n\n// In HelloWxWorldFrame\nprivate: void HelloWxWorldFrame::OnAbout(wxCommandEvent &event)"
// get string array of hover info separated at /n chars.
@@ -2670,7 +2671,8 @@ void Parser::OnLSP_SignatureHelpResponse(wxCommandEvent& event, std::vector<cbCo
json signatures = pJson->at("result").at("signatures");
for (size_t labelndx=0; labelndx<signatureCount && labelndx<10; ++labelndx)
{
- wxString labelValue = signatures[labelndx].at("label").get<std::string>();
+ std::string labelValueStdString = signatures[labelndx].at("label").get<std::string>();
+ wxString labelValue(labelValueStdString.c_str(), wxConvUTF8);
v_SignatureTokens.push_back(cbCodeCompletionPlugin::CCCallTip(labelValue));
}
I'm not sure the second hunk is needed, but the first hunk is the true fix.
idValue = GetwxUTF8Str(pJson->at("id").get<std::string>());
wxString GetwxUTF8Str(const std::string stdString)
{
return wxString(stdString.c_str(), wxConvUTF8);
}
{"id":"textDocument/hover","jsonrpc":"2.0","method":"textDocument/hover","params":{"position":{"character":4,"line":3},"textDocument":{"uri":"file:///F:/code/test_clangd_client_tipwin/main.cpp"}}}
15:06:48.772 >>> readJson() len:220:
{"id":"textDocument/hover","jsonrpc":"2.0","result":{"contents":{"kind":"plaintext","value":"variable m_AAA\n\nType: int\nABCDEFG\n\nint m_AAA"},"range":{"end":{"character":9,"line":3},"start":{"character":4,"line":3}}}}
15:07:41.294 <<< Hover:
file:///F:/code/test_clangd_client_tipwin/main.cpp,line[1], char[4]
15:07:41.294 <<< Content-Length: 196
{"id":"textDocument/hover","jsonrpc":"2.0","method":"textDocument/hover","params":{"position":{"character":4,"line":1},"textDocument":{"uri":"file:///F:/code/test_clangd_client_tipwin/main.cpp"}}}
15:07:41.524 >>> readJson() len:240:
{"id":"textDocument/hover","jsonrpc":"2.0","result":{"contents":{"kind":"plaintext","value":"variable m_TcpFile\n\nType: int\nTCP鎺ユ敹鐨勬暟鎹甛n\nint m_TcpFile"},"range":{"end":{"character":13,"line":1},"start":{"character":4,"line":1}}}}
int m_TcpFile; ///< TCP接收的数据
int m_AAA; ///< ABCDEFG
int main()
{
return 0;
}
// Example Hover contents: L"instance-method HelloWxWorldFrame::OnAbout\n\nType: void\nParameters:\n- wxCommandEvent & event\n\n// In HelloWxWorldFrame\nprivate: void HelloWxWorldFrame::OnAbout(wxCommandEvent &event)"
// get string array of hover info separated at /n chars.
wxString hoverString = contentsValue;
hoverString.Replace("\n\n", "\n"); //remove double newline chars
wxArrayString vHoverInfo = GetArrayFromString(hoverString, "\n");
// **Debugging**
// LogManager* pLogMgr = Manager::Get()->GetLogManager();
// for (size_t ii=0; ii<vHoverInfo.size(); ++ii)
// pLogMgr->DebugLog(wxString::Format("vHoverInfo[%d]:%s", int(ii), vHoverInfo[ii]));
// Find items from hover data and cut the chaff
wxString hoverText;
for (size_t ii=0, foundIn=false; ii<vHoverInfo.size(); ++ii)
{
if (ii < 2) hoverText += vHoverInfo[ii] + "\n"; //type and return value
if (vHoverInfo[ii].StartsWith("// In ")) //parent
{
hoverText += vHoverInfo[ii] += "\n";
foundIn = true; continue;
}
if (foundIn) hoverText += vHoverInfo[ii] + "\n";;
}//endfor vHoverInfo
v_HoverTokens.push_back(ClgdCCToken(0, hoverText, hoverText));
clangd_client/src/codecompletion/parser/parser.cpp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/clangd_client/src/codecompletion/parser/parser.cpp b/clangd_client/src/codecompletion/parser/parser.cpp
index 6852ee2..4706432 100644
--- a/clangd_client/src/codecompletion/parser/parser.cpp
+++ b/clangd_client/src/codecompletion/parser/parser.cpp
@@ -2563,13 +2563,14 @@ void Parser::OnLSP_HoverResponse(wxCommandEvent& event, std::vector<ClgdCCToken>
wxString hoverText;
for (size_t ii=0, foundIn=false; ii<vHoverInfo.size(); ++ii)
{
- if (ii < 2) hoverText += vHoverInfo[ii] + "\n"; //type and return value
if (vHoverInfo[ii].StartsWith("// In ")) //parent
{
hoverText += vHoverInfo[ii] += "\n";
foundIn = true; continue;
}
- if (foundIn) hoverText += vHoverInfo[ii] + "\n";;
+ if (foundIn) hoverText += vHoverInfo[ii] + "\n";
+
+ if (ii < 3) hoverText += vHoverInfo[ii] + "\n"; //type and return value [0]: kind, [1]: type, [2]: comments
}//endfor vHoverInfo
v_HoverTokens.push_back(ClgdCCToken(0, hoverText, hoverText));
variable m_AAA\n\nType: int\nABCDEFG\n\nint m_AAA
I did some extra test of how to show the comments.
Here is the log file from CBclangd_client-xxxxx.log:Code...
15:07:41.524 >>> readJson() len:240:
{"id":"textDocument/hover","jsonrpc":"2.0","result":{"contents":{"kind":"plaintext","value":"variable m_TcpFile\n\nType: int\nTCP鎺ユ敹鐨勬暟鎹甛n\nint m_TcpFile"},"range":{"end":{"character":13,"line":1},"start":{"character":4,"line":1}}}}
int\nTCP鎺ユ敹鐨勬暟鎹甛n\n
clangd_client/src/LSPclient/client.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clangd_client/src/LSPclient/client.cpp b/clangd_client/src/LSPclient/client.cpp
index c4a7729..76d19ca 100644
--- a/clangd_client/src/LSPclient/client.cpp
+++ b/clangd_client/src/LSPclient/client.cpp
@@ -1020,7 +1020,7 @@ bool ProcessLanguageClient::readJson(json &json)
m_MutexInputBufGuard.Unlock();
if (stdStrInputbuf.size())
- writeClientLog(wxString::Format(">>> readJson() len:%d:\n%s", length, stdStrInputbuf.c_str()) );
+ writeClientLog(wxString::Format(">>> readJson() len:%d:\n%s", length, GetwxUTF8Str(stdStrInputbuf.c_str()).wx_str()) );
// remove any invalid utf8 chars
bool validData = DoValidateUTF8data(stdStrInputbuf);
I created a patch which can show the "doxygen comments".
...
@pecanYes, I was finally able to replicate the issue and fix it in the new Nightly 221008.
About my replay #203....
I read the message in which you said you are unable to replicate the issue. I was about to create a test project but it seems that your messagewas deleted. Do you replicated the issue?
I did some extra test of how to show the comments.
Here is the log file from CBclangd_client-xxxxx.log:Code...
15:07:41.524 >>> readJson() len:240:
{"id":"textDocument/hover","jsonrpc":"2.0","result":{"contents":{"kind":"plaintext","value":"variable m_TcpFile\n\nType: int\nTCP鎺ユ敹鐨勬暟鎹甛n\nint m_TcpFile"},"range":{"end":{"character":13,"line":1},"start":{"character":4,"line":1}}}}
The log file shows the wrong Chinese words.Codeint\nTCP鎺ユ敹鐨勬暟鎹甛n\n
The following patch solves this issue:Codeclangd_client/src/LSPclient/client.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clangd_client/src/LSPclient/client.cpp b/clangd_client/src/LSPclient/client.cpp
index c4a7729..76d19ca 100644
--- a/clangd_client/src/LSPclient/client.cpp
+++ b/clangd_client/src/LSPclient/client.cpp
@@ -1020,7 +1020,7 @@ bool ProcessLanguageClient::readJson(json &json)
m_MutexInputBufGuard.Unlock();
if (stdStrInputbuf.size())
- writeClientLog(wxString::Format(">>> readJson() len:%d:\n%s", length, stdStrInputbuf.c_str()) );
+ writeClientLog(wxString::Format(">>> readJson() len:%d:\n%s", length, GetwxUTF8Str(stdStrInputbuf.c_str()).wx_str()) );
// remove any invalid utf8 chars
bool validData = DoValidateUTF8data(stdStrInputbuf);
About my replay #203....
Yes, I was finally able to replicate the issue and fix it in the new Nightly 221008.
In clangd_client rev 83, I've completely reworked writing to the logs.
The purpose of the logs (for me) is to see exactly what clangd was sending to the CB client. My prior code was not accomplishing that. It was converting std:strings (from clangd) to wxStrings. I should not have done that.
I changed the log code to record the std:strings as clangd sent them, which is much more accurate in my estimation.
Would you retest the the error you're getting to see if rev 83 also gets the error.
If it does, I'd rather fix it using the conversion methods you and sodev suggested in other forum messages without modifying the logs.
Thanks for testing.
{"id":"textDocument/hover","jsonrpc":"2.0","method":"textDocument/hover","params":{"position":{"character":4,"line":5},"textDocument":{"uri":"file:///F:/code/test_clangd_client_tipwin/main.cpp"}}}
19:59:55.500 >>> readJson() len:220:
{"id":"textDocument/hover","jsonrpc":"2.0","result":{"contents":{"kind":"plaintext","value":"variable m_AAA\n\nType: int\nABCDEFG\n\nint m_AAA"},"range":{"end":{"character":9,"line":5},"start":{"character":4,"line":5}}}}
19:59:58.665 <<< Hover:
file:///F:/code/test_clangd_client_tipwin/main.cpp,line[1], char[4]
19:59:58.666 <<< Content-Length: 196
{"id":"textDocument/hover","jsonrpc":"2.0","method":"textDocument/hover","params":{"position":{"character":4,"line":1},"textDocument":{"uri":"file:///F:/code/test_clangd_client_tipwin/main.cpp"}}}
19:59:58.750 >>> readJson() len:240:
{"id":"textDocument/hover","jsonrpc":"2.0","result":{"contents":{"kind":"plaintext","value":"variable m_TcpFile\n\nType: int\nTCP鎺ユ敹鐨勬暟鎹甛n\nint m_TcpFile"},"range":{"end":{"character":13,"line":1},"start":{"character":4,"line":1}}}}
-------------------- clangd_client/src/LSPclient/client.cpp --------------------
index faecc9c..e92c789 100644
@@ -1068,7 +1068,7 @@ bool ProcessLanguageClient::readJson(json &json)
m_MutexInputBufGuard.Unlock();
if (stdStrInputbuf.size())
- writeClientLog(StdString_Format(">>> readJson() len:%d:\n%s", length, stdStrInputbuf.c_str()) );
+ writeClientLog(StdString_Format(">>> readJson() len:%d:\n", length) + stdStrInputbuf);
// remove any invalid utf8 chars
bool validData = DoValidateUTF8data(stdStrInputbuf);
// Example Hover contents: L"instance-method HelloWxWorldFrame::OnAbout\n\nType: void\nParameters:\n- wxCommandEvent & event\n\n// In HelloWxWorldFrame\nprivate: void HelloWxWorldFrame::OnAbout(wxCommandEvent &event)"
// get string array of hover info separated at /n chars.
wxString hoverString = contentsValue;
@MaxGaspa
About my reply #203....
Yes, I was finally able to replicate the issue and fix it in the new Nightly 221008.
Pecan, I do not want to bore you....
Yes you fixed the issue related to my message #205 but the bugs in #203 is still present (latest nightly and plugin, Win7 and Win10).
I'm observing the plugin in "sleep state" in several way but the one in #203 seems the simpler test case. The most surprising thing is that I need to close CB to force a reparse...
If you need a test project to replicate the issue let me know.
Thank you anyway for your plugin...is usable and good (IMHO)
MAx
But I still got the same error result of Chinese chars. :(
// ----------------------------------------------------------------------------
void ProcessLanguageClient::writeClientLog(const std::string& logmsg)
// ----------------------------------------------------------------------------
{
if (not lspClientLogFile.IsOpened()) return;
std::string logcr = "";
if (not StdString_EndsWith(logmsg, "\n"))
logcr = "\n";
lspClientLogFile.Write("\n" + GetTime_in_HH_MM_SS_MMM() + " " + logmsg + logcr);
lspClientLogFile.Flush();
}
// ----------------------------------------------------------------------------
void ProcessLanguageClient::writeServerLog(const std::string& logmsg)
// ----------------------------------------------------------------------------
{
if (not lspServerLogFile.IsOpened()) return;
lspServerLogFile.Write(logmsg);
lspServerLogFile.Flush();
-------------------- clangd_client/src/LSPclient/client.cpp --------------------
index e92c789..5c56b26 100644
@@ -626,7 +626,7 @@ void ProcessLanguageClient::writeClientLog(const std::string& logmsg)
std::string logcr = "";
if (not StdString_EndsWith(logmsg, "\n"))
logcr = "\n";
- lspClientLogFile.Write("\n" + GetTime_in_HH_MM_SS_MMM() + " " + logmsg + logcr);
+ lspClientLogFile.Write("\n" + GetTime_in_HH_MM_SS_MMM() + " " + GetwxUTF8Str(logmsg) + logcr);
lspClientLogFile.Flush();
}
// ----------------------------------------------------------------------------
@@ -634,7 +634,7 @@ void ProcessLanguageClient::writeServerLog(const std::string& logmsg)
// ----------------------------------------------------------------------------
{
if (not lspServerLogFile.IsOpened()) return;
- lspServerLogFile.Write(logmsg);
+ lspServerLogFile.Write(GetwxUTF8Str(logmsg));
lspServerLogFile.Flush();
//(ph 2022/02/16)
Hi, Pecan, my guess is correct. ;)Code-------------------- clangd_client/src/LSPclient/client.cpp --------------------
index e92c789..5c56b26 100644
@@ -626,7 +626,7 @@ void ProcessLanguageClient::writeClientLog(const std::string& logmsg)
std::string logcr = "";
if (not StdString_EndsWith(logmsg, "\n"))
logcr = "\n";
- lspClientLogFile.Write("\n" + GetTime_in_HH_MM_SS_MMM() + " " + logmsg + logcr);
+ lspClientLogFile.Write("\n" + GetTime_in_HH_MM_SS_MMM() + " " + GetwxUTF8Str(logmsg) + logcr);
lspClientLogFile.Flush();
}
// ----------------------------------------------------------------------------
@@ -634,7 +634,7 @@ void ProcessLanguageClient::writeServerLog(const std::string& logmsg)
// ----------------------------------------------------------------------------
{
if (not lspServerLogFile.IsOpened()) return;
- lspServerLogFile.Write(logmsg);
+ lspServerLogFile.Write(GetwxUTF8Str(logmsg));
lspServerLogFile.Flush();
//(ph 2022/02/16)
With this patch, the log file is correctly showing the non-ascii characters.
There is no need for the logs to show only ascii chars.
I hex dumped that section of the log. Those non ascii chars are each legal utf8 3byte hex representations of one char.
At the point we need to use/display them, we do the GetwxUTF8String() to convert them to wxStrings.
That works just fine.
Please do not convert the logs. I need them to look just the same as clangd sent to us. Especially when trying to document possible bugs.
Thanks for the work you do. I'm grateful.
bool Write (const wxString &str, const wxMBConv &conv=wxConvAuto())
// ----------------------------------------------------------------------------
void ProcessLanguageClient::writeClientLog(const std::string& logmsg)
// ----------------------------------------------------------------------------
{
if (not lspClientLogFile.IsOpened()) return;
std::string logcr = "";
if (not StdString_EndsWith(logmsg, "\n"))
logcr = "\n";
lspClientLogFile.Write("\n" + GetTime_in_HH_MM_SS_MMM() + " " + logmsg + logcr);
lspClientLogFile.Flush();
}
arg0 = "\n" + GetTime_in_HH_MM_SS_MMM() + " " + logmsg + logcr
size_t Write (const void *buffer, size_t count)
...Partial quote....
Yes you fixed the issue related to my message #205 but the bugs in #203 is still present (latest nightly and plugin, Win7 and Win10).
I'm observing the plugin in "sleep state" in several way but the one in #203 seems the simpler test case. The most surprising thing is that I need to close CB to force a reparse...
If you need a test project to replicate the issue let me know.
Thank you anyway for your plugin...is usable and good (IMHO)
MAx
// ----------------------------------------------------------------------------
void ProcessLanguageClient::writeClientLog(const std::string& logmsg)
// ----------------------------------------------------------------------------
{
if (not lspClientLogFile.IsOpened()) return;
std::string logcr = "";
if (not StdString_EndsWith(logmsg, "\n"))
logcr = "\n";
std::string out = "\n" + GetTime_in_HH_MM_SS_MMM() + " " + logmsg + logcr;
lspClientLogFile.Write(out.c_str(), out.size());
lspClientLogFile.Flush();
}
// ----------------------------------------------------------------------------
void ProcessLanguageClient::writeServerLog(const std::string& logmsg)
// ----------------------------------------------------------------------------
{
if (not lspServerLogFile.IsOpened()) return;
lspServerLogFile.Write(logmsg.c_str(), logmsg.size());
lspServerLogFile.Flush();
@ olldbg RE: Reply #218 on: October 11, 2022, 02:44:26
Thanks, it works for me.
Will be in rev 85.Code// ----------------------------------------------------------------------------
void ProcessLanguageClient::writeClientLog(const std::string& logmsg)
// ----------------------------------------------------------------------------
{
if (not lspClientLogFile.IsOpened()) return;
std::string logcr = "";
if (not StdString_EndsWith(logmsg, "\n"))
logcr = "\n";
std::string out = "\n" + GetTime_in_HH_MM_SS_MMM() + " " + logmsg + logcr;
lspClientLogFile.Write(out.c_str(), out.size());
lspClientLogFile.Flush();
}
// ----------------------------------------------------------------------------
void ProcessLanguageClient::writeServerLog(const std::string& logmsg)
// ----------------------------------------------------------------------------
{
if (not lspServerLogFile.IsOpened()) return;
lspServerLogFile.Write(logmsg.c_str(), logmsg.size());
lspServerLogFile.Flush();
// ----------------------------------------------------------------------------
void ClgdCompletion::OnCompilerStarted(CodeBlocksEvent& event)
// ----------------------------------------------------------------------------
{
//If this is a idCompileMenuRun only, do not set compiler is running
// else we'll hang before nightly rev 12975 fix
//#warning Developer should remove this condition after nightly for CB rev 12975
//if (ns_CompilerEventId == XRCID("idCompilerMenuRun")) return;
GetParseManager()->SetCompilerIsRunning(true);
}
//if (ns_CompilerEventId == XRCID("idCompilerMenuRun")) return;
Hi, I'm building clangd_client rev84 with the latest C::B rev 12976.
Do I need to change the line to this:Code// ----------------------------------------------------------------------------
void ClgdCompletion::OnCompilerStarted(CodeBlocksEvent& event)
// ----------------------------------------------------------------------------
{
//If this is a idCompileMenuRun only, do not set compiler is running
// else we'll hang before nightly rev 12975 fix
//#warning Developer should remove this condition after nightly for CB rev 12975
//if (ns_CompilerEventId == XRCID("idCompilerMenuRun")) return;
GetParseManager()->SetCompilerIsRunning(true);
}
I have to comment out the lineCode//if (ns_CompilerEventId == XRCID("idCompilerMenuRun")) return;
Am I correct?
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.
limitedLogOut = wxString::Format("<<< Write():\n%s", wxString(in)).Mid(0,512) + "<...DATA SNIPED BY LOG WRITE()...>";
// Write raw data to clangd server
#if defined(_WIN32)
bool ok = m_pServerProcess->WriteRaw( out ); //windows
if (not ok)
{
writeClientLog("Error: WriteHdr() failed WriteRaw()");
return false;
}
#else
// unix just posts the msg to an output thread queue, so no return code.
m_pServerProcess->Write( fileUtils.ToStdString(out) ); //unix
#endif
bool WinProcessImpl::Write(const std::string& buff) { return WriteRaw(buff + "\r\n"); }
bool WinProcessImpl::WriteRaw(const wxString& buff) { return WriteRaw(FileUtils::ToStdString(buff)); }
bool WinProcessImpl::WriteRaw(const std::string& buff)
{
// Sanity
if(!IsRedirect()) {
return false;
}
m_writerThread->Write(buff);
return true;
}
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:CodelimitedLogOut = wxString::Format("<<< Write():\n%s", wxString(in)).Mid(0,512) + "<...DATA SNIPED BY LOG WRITE()...>";
The variable in to wxString will use wrong encoding.
So, what I think is that we should use std::string inside the WriteHdr().
[/code]
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.
@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
<Partial quote>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:CodelimitedLogOut = wxString::Format("<<< Write():\n%s", wxString(in)).Mid(0,512) + "<...DATA SNIPED BY LOG WRITE()...>";
The variable in to wxString will use wrong encoding.
So, what I think is that we should use std::string inside the WriteHdr().
[/code]
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.
<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>
[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]
<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>
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)-
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 (https://forums.codeblocks.org/index.php/topic,25161.msg171549.html#msg171549)
But when I have only two plugins to load, in the debug-plugin.conf file,
This means only those two dlls get loaded.
But when debugging, I see the debugee codeblocks will report that:
<...some content snipped by pecan...>
The Clangd client plugin cannot run while the "Code completion"
plugin is enabled.
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:
The situation is: if the codecompletion plugin never get loaded, I have no way to enable the clangd_client plugin. :(
I see another crash caught by GDB.CodeFrom 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)-
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.
...
I've reworked the code that attempts to avoid running clangd_client when CodeCompletion is enabled.
This situation was caused by:
1) CodeCompletion.dll plugin is missing but the .conf say that it's enabled.
2) CodeCompletion is loaded by PluginManager but there's no info about it in the .conf file.
Hope I've solved these situations in clangd_client repo rev 87.
when we activate this new improved way in our nightly builds ?
Is it usable enough (I haven't tried it yet I must admit) to promote to a contrib plug-in ?
I
...+1.
...
But I'd like to hear how other users feel about it becoming a contrib.
I see a bug that when the source code has TAB as the indent chars, our C::B editor will report the wrong position to clangd.
It looks like clangd just recognize the TAB as a single char, but in our C::B editor, when we get the column position, a TAB may be recognized as "4 space", in this case, when the clangd_client send the request to the LSP server, it send the wrong column position.
Do you see this bug?
To fix this issue, I think we have to adjust the column position we got from the editor. Any ideas?
EDIT:
The GetColumn() function has such document:
Retrieve the column number of a position, taking tab width into account.
EDIT2
In this page, we can get a "char" based column:
get column number Issue #75 jacobslusser/ScintillaNET (https://github.com/jacobslusser/ScintillaNET/issues/75)
From 8acd4b5b3bfe74d36583c54c4539dda112c6b1f3 Mon Sep 17 00:00:00 2001
From: asmwarrior <a@b.com>
Date: Sat, 5 Nov 2022 18:09:48 +0800
Subject: handling the char based column, do not take account the TAB width
diff --git a/clangd_client/src/LSPclient/client.cpp b/clangd_client/src/LSPclient/client.cpp
index 1654e1d..424fd0a 100644
--- a/clangd_client/src/LSPclient/client.cpp
+++ b/clangd_client/src/LSPclient/client.cpp
@@ -2301,7 +2301,10 @@ void ProcessLanguageClient::LSP_GoToDefinition(cbEditor* pcbEd, int argCaretPosi
//-const int startPosn = pCtrl->WordStartPosition(edCaretPosn, true);
//-const int endPosn = pCtrl->WordEndPosition(posn, true); //not needed
position.line = edLineNum;
- position.character = edColumn;
+
+ int linePos = pCtrl->PositionFromLine(edLineNum); // Retrieve the position at the start of a line.
+ int fauxColumn = edCaretPosn - linePos;
+ position.character = fauxColumn;
writeClientLog(StdString_Format("<<< GoToDefinition:\n%s,line[%d], char[%d]", docuri.c_str(), position.line, position.character) );
//Tell LSP server if text has changed
@@ -2386,7 +2389,9 @@ void ProcessLanguageClient::LSP_GoToDeclaration(cbEditor* pcbEd, int argCaretPos
DocumentUri docuri = DocumentUri(stdFileURI.c_str());
Position position;
position.line = edLineNum;
- position.character = edColumn;
+
+ int linePos = pCtrl->PositionFromLine(edLineNum); // Retrieve the position at the start of a line.
+ int fauxColumn = edCaretPosn - linePos;
writeClientLog(StdString_Format("<<< GoToDeclaration:\n%s,line[%d], char[%d]", docuri.c_str(), position.line, position.character) );
// Tell server if text has changed
@@ -2476,7 +2481,18 @@ void ProcessLanguageClient::LSP_FindReferences(cbEditor* pEd, int argCaretPositi
//-int startPosn = pCtrl->WordStartPosition(caretPosn, true);
//-const int endPosn = pCtrl->WordEndPosition(posn, true); //not needed
position.line = edLineNum;
- position.character = edColumn;
+
+ // the clangd need char based column, where a TAB equals one char
+ // but GetColumn() function just return the column which retrieves the column number of a position, taking tab width into account.
+ // so we need a hack to get a new fauxColumn
+ // get column number Issue #75 jacobslusser/ScintillaNET - https://github.com/jacobslusser/ScintillaNET/issues/75
+ // var currentPos = scintilla.CurrentPosition;
+ // var currentLine = scintilla.LineFromPosition(currentPos);
+ // var linePos = scintilla.Lines[currentLine].Position;
+ // var fauxColumn = (currentPos - linePos);
+ int linePos = pCtrl->PositionFromLine(edLineNum); // Retrieve the position at the start of a line.
+ int fauxColumn = caretPosn - linePos;
+ position.character = fauxColumn;
writeClientLog(StdString_Format("<<< FindReferences:\n%s,line[%d], char[%d]", docuri.c_str(), position.line, position.character) );
// Report changes to server else reported line references will be wrong.
Other issue is that it looks like the icons are not showing correctly, it looks like the transparent color is shown in black?
See the image shot below:
Other issue is that it looks like the icons are not showing correctly, it looks like the transparent color is shown in black?
See the image shot below:
How are seeing those icons.
I don't remember displaying them in clangd_client.
Are you sure you're using clangd_client?
I really didn't want to use the icons. But instead use the extra column for useful data.
I have one question: when I click the context menu->find reference. I see from the client log, there are also "goto declaration" and "goto definition" messages from the json RPC. Do we really need those extra 2 messages? I see find reference messages already correctly return the positions we needed.
I see a bug that when the source code has TAB as the indent chars, our C::B editor will report the wrong position to clangd.
It looks like clangd just recognize the TAB as a single char, but in our C::B editor, when we get the column position, a TAB may be recognized as "4 space", in this case, when the clangd_client send the request to the LSP server, it send the wrong column position.
Do you see this bug?
To fix this issue, I think we have to adjust the column position we got from the editor. Any ideas?
EDIT:
The GetColumn() function has such document:
Retrieve the column number of a position, taking tab width into account.
EDIT2
In this page, we can get a "char" based column:
get column number Issue #75 jacobslusser/ScintillaNET (https://github.com/jacobslusser/ScintillaNET/issues/75)
This issue can be fixed by this patch:CodeFrom 8acd4b5b3bfe74d36583c54c4539dda112c6b1f3 Mon Sep 17 00:00:00 2001
From: asmwarrior <a@b.com>
Date: Sat, 5 Nov 2022 18:09:48 +0800
Subject: handling the char based column, do not take account the TAB width
diff --git a/clangd_client/src/LSPclient/client.cpp b/clangd_client/src/LSPclient/client.cpp
index 1654e1d..424fd0a 100644
--- a/clangd_client/src/LSPclient/client.cpp
+++ b/clangd_client/src/LSPclient/client.cpp
@@ -2301,7 +2301,10 @@ void ProcessLanguageClient::LSP_GoToDefinition(cbEditor* pcbEd, int argCaretPosi
//-const int startPosn = pCtrl->WordStartPosition(edCaretPosn, true);
//-const int endPosn = pCtrl->WordEndPosition(posn, true); //not needed
position.line = edLineNum;
- position.character = edColumn;
+
+ int linePos = pCtrl->PositionFromLine(edLineNum); // Retrieve the position at the start of a line.
+ int fauxColumn = edCaretPosn - linePos;
+ position.character = fauxColumn;
writeClientLog(StdString_Format("<<< GoToDefinition:\n%s,line[%d], char[%d]", docuri.c_str(), position.line, position.character) );
//Tell LSP server if text has changed
@@ -2386,7 +2389,9 @@ void ProcessLanguageClient::LSP_GoToDeclaration(cbEditor* pcbEd, int argCaretPos
DocumentUri docuri = DocumentUri(stdFileURI.c_str());
Position position;
position.line = edLineNum;
- position.character = edColumn;
+
+ int linePos = pCtrl->PositionFromLine(edLineNum); // Retrieve the position at the start of a line.
+ int fauxColumn = edCaretPosn - linePos;
writeClientLog(StdString_Format("<<< GoToDeclaration:\n%s,line[%d], char[%d]", docuri.c_str(), position.line, position.character) );
// Tell server if text has changed
@@ -2476,7 +2481,18 @@ void ProcessLanguageClient::LSP_FindReferences(cbEditor* pEd, int argCaretPositi
//-int startPosn = pCtrl->WordStartPosition(caretPosn, true);
//-const int endPosn = pCtrl->WordEndPosition(posn, true); //not needed
position.line = edLineNum;
- position.character = edColumn;
+
+ // the clangd need char based column, where a TAB equals one char
+ // but GetColumn() function just return the column which retrieves the column number of a position, taking tab width into account.
+ // so we need a hack to get a new fauxColumn
+ // get column number Issue #75 jacobslusser/ScintillaNET - https://github.com/jacobslusser/ScintillaNET/issues/75
+ // var currentPos = scintilla.CurrentPosition;
+ // var currentLine = scintilla.LineFromPosition(currentPos);
+ // var linePos = scintilla.Lines[currentLine].Position;
+ // var fauxColumn = (currentPos - linePos);
+ int linePos = pCtrl->PositionFromLine(edLineNum); // Retrieve the position at the start of a line.
+ int fauxColumn = caretPosn - linePos;
+ position.character = fauxColumn;
writeClientLog(StdString_Format("<<< FindReferences:\n%s,line[%d], char[%d]", docuri.c_str(), position.line, position.character) );
// Report changes to server else reported line references will be wrong.
jacobslusser commented on Jul 12, 2015
TL;DR
The GetColumn method.
That's an interesting question when you think about it... We could use the CurrentPosition property to get the position of the caret within the document; use that with LineFromPosition to get the line index; get the line start position from Line.Position and then finally subtract that from the original caret position to get the "column":
var currentPos = scintilla.CurrentPosition;
var currentLine = scintilla.LineFromPosition(currentPos);
var linePos = scintilla.Lines[currentLine].Position;
var fauxColumn = (currentPos - linePos);
This wouldn't be the "column" though (hence my fauxColumn variable name). Why? Because it doesn't account for tab characters which can occupy 4, 8, or any other amount of spaces. Usually when someone says they want the "column", they want the line space as it would show on a ruler, which is not necessarily the number of characters. To get a column position--while also taking into account the tab size--use the GetColumn method:
var column = scintilla.GetColumn(scintilla.CurrentPosition);
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.
My guess the logic here is: once the editor get opened, the content will be sent to the LSP. But if the parsing is not finished, the hover event will report that the File not parsed yet. But I'm not sure sometimes, it will always popup. I have to close the project, and re-open the project to workaround this issue.
Maybe there are some options which affect this issue. My guess is the option:
Update parser when typing (on save otherwise).
@ollydbgIt's good that you can reproduce it.
RE: #244 Tab character.
Would you provide me with an example text files with Tabs that create this situation. I'd like to debug trace through the code.
Also what is your editor setting for tabs?
Thanks
Edit:
Never mind. I finally figured it out by adding both fixes and keeping the one that works. Namey ollydbgs fix.
"var column = scintilla.GetColumn(scintilla.CurrentPosition);"
does not fix the problem. It causes the same problem when tabs are in the source line.
int main()
{
int abc = 0;
int xyz = abc + abc;
return 0;
}
It's good that you can reproduce it.
I just prepared the test code, it is very simple:Codeint main()
{
int abc = 0;
int xyz = abc + abc;
return 0;
}
And all use "tab" as indent.
Here is the screen shot.
Find declaration shows nothing, see the information message.
Find reference shows only one line, see the list view, it should show 2 lines.
Here is the screen shot:
cd trunk
./bootstrap
./configure
make
pecan@Zbook17:~/proj/cbHeadM4/trunk$ find . -name ".libs"
./src/src/.libs
./src/sdk/mozilla_chardet/src/.libs
./src/sdk/wxscintilla/src/scintilla/src/.libs
./src/sdk/wxscintilla/src/scintilla/lexlib/.libs
./src/sdk/wxscintilla/src/scintilla/lexers/.libs
./src/sdk/wxscintilla/src/.libs
./src/sdk/wxscintilla/.libs
./src/sdk/scripting/sqstdlib/.libs
./src/sdk/scripting/squirrel/.libs
./src/sdk/scripting/bindings/.libs
./src/sdk/.libs
./src/build_tools/autorevision/.libs
./src/plugins/codecompletion/.libs
./src/plugins/codecompletion/parser/.libs
./src/plugins/astyle/astyle/.libs
./src/plugins/astyle/.libs
./src/plugins/scriptedwizard/.libs
./src/plugins/compilergcc/.libs
./src/plugins/compilergcc/depslib/src/.libs
./src/plugins/todo/.libs
./src/plugins/defaultmimehandler/.libs
./src/plugins/debuggergdb/.libs
./src/plugins/projectsimporter/.libs
./src/plugins/openfileslist/.libs
./src/plugins/classwizard/.libs
./src/plugins/occurrenceshighlighting/.libs
./src/plugins/abbreviations/.libs
./src/plugins/autosave/.libs
./src/base/tinyxml/.libs
./src/tools/cb_share_config/.libs
./src/tools/ConsoleRunner/.libs
......
@ollydbg
RE: #244 Tab character.
Tab char column determination fixed in Clangd_client rev 88.
Give it a try.
Thanks for the fix.
https://sourceforge.net/p/cb-clangd-client/code/88/
From 96e57a13033c2f67e45813ad423e2d6c077488bb Mon Sep 17 00:00:00 2001
From: asmwarrior <a@b.com>
Date: Sat, 5 Nov 2022 18:10:33 +0800
Subject: change the annoying messagebox to log
diff --git a/clangd_client/src/codecompletion/parser/LSP_symbolsparser.cpp b/clangd_client/src/codecompletion/parser/LSP_symbolsparser.cpp
index 65c2c5a..a2868de 100644
--- a/clangd_client/src/codecompletion/parser/LSP_symbolsparser.cpp
+++ b/clangd_client/src/codecompletion/parser/LSP_symbolsparser.cpp
@@ -2198,7 +2198,9 @@ Token* LSP_SymbolsParser::DoHandleClass(EClassType ct, int lineNumber, int lastL
newToken->m_IsAnonymous = true;
#if defined(cbDEBUG)
wxString msg((wxString::Format("Trying to DoParse recursion in %s():%d", __FUNCTION__, __LINE__)));
- cbMessageBox(msg, "Assert(non fatal)");
+ CCLogger::Get()->DebugLog(msg);
+ wxString str = wxString::Format("m_Buffer = %s, next = %s", m_Buffer, next);
+ //cbMessageBox(msg, "Assert(non fatal)");
#endif
break; //(ph 2021/10/13)
/// DoParse(); // recursion
...
When editing the "#include <" or other statement, I see an annoying messagebox, I just translate the messagebox to log:CodeFrom 96e57a13033c2f67e45813ad423e2d6c077488bb Mon Sep 17 00:00:00 2001
From: asmwarrior <a@b.com>
Date: Sat, 5 Nov 2022 18:10:33 +0800
Subject: change the annoying messagebox to log
diff --git a/clangd_client/src/codecompletion/parser/LSP_symbolsparser.cpp b/clangd_client/src/codecompletion/parser/LSP_symbolsparser.cpp
index 65c2c5a..a2868de 100644
--- a/clangd_client/src/codecompletion/parser/LSP_symbolsparser.cpp
+++ b/clangd_client/src/codecompletion/parser/LSP_symbolsparser.cpp
@@ -2198,7 +2198,9 @@ Token* LSP_SymbolsParser::DoHandleClass(EClassType ct, int lineNumber, int lastL
newToken->m_IsAnonymous = true;
#if defined(cbDEBUG)
wxString msg((wxString::Format("Trying to DoParse recursion in %s():%d", __FUNCTION__, __LINE__)));
- cbMessageBox(msg, "Assert(non fatal)");
+ CCLogger::Get()->DebugLog(msg);
+ wxString str = wxString::Format("m_Buffer = %s, next = %s", m_Buffer, next);
+ //cbMessageBox(msg, "Assert(non fatal)");
#endif
break; //(ph 2021/10/13)
/// DoParse(); // recursion
BTW: I really do not know why this happens, do you want to parse a single line using the hand written parser ourselves?
#if defined(cbDEBUG)
// FIXME (ph#): Find out why this happens when trying to find a class ancestor.
wxString msg((wxString::Format("Trying to DoParse recursion in %s():%d", __FUNCTION__, __LINE__)));
//-cbMessageBox(msg, "Assert(non fatal)");
CCLogger::Get()->DebugLog(msg);
#endif
break; //(ph 2021/10/13)
/// DoParse(); // recursion
<Add option="-m64" />
Cool.
I see that clangd_client plugin is now included in contrib plugins.
Three details :
- within contrib, it's version 87 though on your svn site it's version 88;
- CodeBlocks_wx32_64.workspace has not been updated to include the clangd_client but all other workspaces are OK;
- the documentation-install folder is not there.
gd_on
File clangd_client_wx31.cbp has this linker option:Fixed rev 13031. ThanksCodebut it is a 32-bit project.<Add option="-m64" />
Conversely, clangd_client_wx32.cbp is missing although CodeBlocks_wx32.workspace includes it (ticket #1327).Fixed rev 13031. Thanks
<Add option="-m64" />
<Add option="-D_WIN64" />
[r12032] fixed most issues, but this compiler options are still invalid for a 32-bit project.Code<Add option="-m64" />
<Add option="-D_WIN64" />
*.depend and *.layout files should be added to svn:ignore
The MSW project creates a clangd_client.zip file in the project folder; If this is OK, it should be added also to svn:ignore
The unix_30 project creates .obj30 and devel30 under the project folder, is this OK?.
c:\Codeblocks>svn status
X src\plugins\contrib\FortranProject
X src\plugins\contrib\PythonPlugins
? src\plugins\contrib\clangd_client\clangd_client_wx32.depend
c:\Codeblocks\src\plugins\contrib\clangd_client>svn proplist -v
Properties on '.':
svn:ignore
*.layout
clangd_client.zip
Properties on '.':
svn:ignore
*.depend
*.layout
*_build_log.html
clangd_client.zip
The .depend is still "active", after compiling the plugin:Codeso *.depends is missing. Other folders (p.e. src/src) add also *_build_log.html, because saving build log to HTML leaves this files around.c:\Codeblocks>svn status
X src\plugins\contrib\FortranProject
X src\plugins\contrib\PythonPlugins
? src\plugins\contrib\clangd_client\clangd_client_wx32.depend
c:\Codeblocks\src\plugins\contrib\clangd_client>svn proplist -v
Properties on '.':
svn:ignore
*.layout
clangd_client.zip
IMHO the ignore list should be:CodeProperties on '.':
svn:ignore
*.depend
*.layout
*_build_log.html
clangd_client.zip
Please go ahead and change them as you see fit.Done. Just go to the plugin directory and write:
svn propedit svn:ignore .
QuotePlease go ahead and change them as you see fit.Done. Just go to the plugin directory and write:Codesvn propedit svn:ignore .
F:\usr\Proj\cbHead\trunk\src\plugins>svn propedit svn:ignore .
svn: E205007: None of the environment variables SVN_EDITOR, VISUAL or EDITOR are set, and no 'editor-cmd' run-time configuration option was found
set SVN_EDITOR=notepad.exe
....
The code is trying to parse out the ancestor of a class to add to the symbols tree. Clangd has no protocol msg to achieve that, so I was trying to use the old CodeCompletion code to parse it from the source line.
Do you have any steps you can give me to re-create the situation.
Thanks
/// comment
class A
{
int m_X;
int m_Y;
};
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 ...
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 ...
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
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());
other questions, what should functions calling 'foo' do, it gives me nothing and opens u[ the tab at the bottom of cscope ?
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 ...
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 ?
I have some situation that there are many information messages showing: LSP: File not yet parsed.Finally !! Caught and fixed in Head rev 13134
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 ...
I have some situation that there are many information messages showing: LSP: File not yet parsed.Finally !! Caught and fixed in Head rev 13134
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 ...
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 :>)
-#define VERSION wxT("1.2.60 22/12/22")
+#define VERSION wxT("1.2.611 22/12/24")
Hi, I see one issue today.
In the latest clangd_client (0.61), I see that "find declaration" and "find implementation" context menu item just do the same thing.
Here, I can see when I click on either item, it just jump between the function declaration and implementation.
I see that the plug-in sometimes put a read square on the left hand side of the editor (because it spots something which is not ok), but where can I see the "message/diagnostic", so I know what it is telling me ?In the LSP messages tab in the log pane
Could you give me some example code that is causing the problem.
Maybe I can be more precise in showing the declaration vs the definition.
#include <iostream>
using namespace std;
class Box {
public:
double length; // Length of a box
double breadth; // Breadth of a box
double height; // Height of a box
// Member functions declaration
double getVolume(void);
void setLength( double len );
void setBreadth( double bre );
void setHeight( double hei );
};
// Member functions definitions
double Box::getVolume(void) {
return length * breadth * height;
}
void Box::setLength( double len ) {
length = len;
}
void Box::setBreadth( double bre ) {
breadth = bre;
}
void Box::setHeight( double hei ) {
height = hei;
}
// Main function for the program
int main() {
Box Box1; // Declare Box1 of type Box
Box Box2; // Declare Box2 of type Box
double volume = 0.0; // Store the volume of a box here
// box 1 specification
Box1.setLength(6.0);
Box1.setBreadth(7.0);
Box1.setHeight(5.0);
// box 2 specification
Box2.setLength(12.0);
Box2.setBreadth(13.0);
Box2.setHeight(10.0);
// volume of box 1
volume = Box1.getVolume();
cout << "Volume of Box1 : " << volume <<endl;
// volume of box 2
volume = Box2.getVolume();
cout << "Volume of Box2 : " << volume <<endl;
return 0;
}
Could you give me some example code that is causing the problem.
Maybe I can be more precise in showing the declaration vs the definition.
I think every C++ member function will demonstrate this issue.
For example, I just searched a simple C++ tutorial here: C++ Class Member Functions (https://www.tutorialspoint.com/cplusplus/cpp_class_member_functions.htm)
And the test code is below:Code#include <iostream>
using namespace std;
class Box {
public:
double length; // Length of a box
double breadth; // Breadth of a box
double height; // Height of a box
// Member functions declaration
double getVolume(void);
void setLength( double len );
void setBreadth( double bre );
void setHeight( double hei );
};
// Member functions definitions
double Box::getVolume(void) {
return length * breadth * height;
}
void Box::setLength( double len ) {
length = len;
}
void Box::setBreadth( double bre ) {
breadth = bre;
}
void Box::setHeight( double hei ) {
height = hei;
}
// Main function for the program
int main() {
Box Box1; // Declare Box1 of type Box
Box Box2; // Declare Box2 of type Box
double volume = 0.0; // Store the volume of a box here
// box 1 specification
Box1.setLength(6.0);
Box1.setBreadth(7.0);
Box1.setHeight(5.0);
// box 2 specification
Box2.setLength(12.0);
Box2.setBreadth(13.0);
Box2.setHeight(10.0);
// volume of box 1
volume = Box1.getVolume();
cout << "Volume of Box1 : " << volume <<endl;
// volume of box 2
volume = Box2.getVolume();
cout << "Volume of Box2 : " << volume <<endl;
return 0;
}
Find declaration of function "getVolume", will jump between from the function declaration in C++ class definition and function body "double Box::getVolume(void)".
BTW: sorry for the late reply, I just recovered from COVID-19 infection.
Is this source all in one .cpp file or split between a .h and .cpp source file ?If you put all the source code in a single .cpp file, find declaration will jump only in a single file between two lines. First from one line to another, and return back.
Glad you made it through covid. I know how awful that suff is. I got it before there was any vaccine. It's dangerous.Thanks, I wish all our devs and C::B users good health, happy coding!
Hi, I see one issue today.
In the latest clangd_client (0.61), I see that "find declaration" and "find implementation" context menu item just do the same thing.
Here, I can see when I click on either item, it just jump between the function declaration and implementation.
Hi, I see one issue today.
In the latest clangd_client (0.61), I see that "find declaration" and "find implementation" context menu item just do the same thing.
Here, I can see when I click on either item, it just jump between the function declaration and implementation.
This "bounce" behavior is how clangd is currently working.
If the user asks for a declaration while positioned on it, clangd will respond with the implementation location and vise versa.
They seem to think that's how a "smart editor" should act.
i.e., "Do what I meant to do" behavior. Read my mind, not my mouse.
https://github.com/clangd/clangd/issues/713
I've spent 25 hours trying to get this to behave how the old CodeCompletion behaved.
Alas, I've failed, since it would require parsing the file text of the "GoTo/Find"response. That would get us back to the problem we're trying to get away from, namely parsing c++ code.
I'm leaving it as is until (maybe) clangd gives us an option to circumvent this behavior.
Suggestions welcomed.
Just some error reporting. During editing the ProjectLoader.cpp from codeblocks i get a lot of this error message dialogs:
I can not find steps to reproduce them, they come on opening file, or editing it, quite random... Sometimes it works...
Would it be possible to not use message boxes for this? Simply logging would be enough i think, message boxes interrupt the user work...
Just some error reporting. During editing the ProjectLoader.cpp from codeblocks i get a lot of this error message dialogs:
I can not find steps to reproduce them, they come on opening file, or editing it, quite random... Sometimes it works...
Would it be possible to not use message boxes for this? Simply logging would be enough i think, message boxes interrupt the user work...
since I build and installed clang16, the plug-in keep asking to specify the path to clangd, though it is in the same location as before, and even explicitly specifying the path does not help.
> which clangd
/opt/llvm/bin/clangd
> clangd --version
clangd version 16.0.0 (https://github.com/llvm/llvm-project.git 08d094a0e457360ad8b94b017d2dc277e697ca76)
Features: linux
Platform: x86_64-unknown-linux-gnu
since I build and installed clang16, the plug-in keep asking to specify the path to clangd, though it is in the same location as before, and even explicitly specifying the path does not help.
> which clangd
/opt/llvm/bin/clangd
> clangd --version
clangd version 16.0.0 (https://github.com/llvm/llvm-project.git 08d094a0e457360ad8b94b017d2dc277e697ca76)
Features: linux
Platform: x86_64-unknown-linux-gnu
#define GPIOA ((GPIO_TypeDef *) GPIOA_BASE)
Index: client.cpp
===================================================================
--- client.cpp (revision 13268)
+++ client.cpp (working copy)
@@ -1890,7 +1890,7 @@
writeClientLog(StdString_Format("<<< Initialize(): %s", stdDirName.c_str()) );
// Set the project folder as the folder containing the commands file. //(ollydbg 2022/10/19) Ticket #75
- try { Initialize(string_ref(fileUtils.FilePathToURI(dirname)), string_ref(dirname.ToUTF8())); } //(ollydbg 2022/10/19) ticket #75
+ try { Initialize(string_ref(fileUtils.FilePathToURI(dirname.ToUTF8())), string_ref(dirname.ToUTF8())); } //(ollydbg 2022/10/19) ticket #75
catch(std::exception &err)
{
//printf("read error -> %s\nread -> %s\n ", e.what(), read.c_str());
Can you write a short example that we can use to re-create your problems?
For me, clangd_client does indeed provide the info you are having problems with.
With an example from you, we might be able to either show you how to get the info, or fix the problem.
My os is win7 , clangd.exe is from latest version LLVM-16.0.5-win64 which full installed ,compiler is winlibs-x86_64-mcf-seh-gcc-13.1.0-mingw-w64ucrt-11.0.0-r1,no msys . In CB , compiler settings is right , search directories is right .
My Project to test clangd_client is simplest "hello world" , add several varialbes and simple classes , the program is normally compiling and running . clangd_client can jump to class( I defines myself) declaration and implementation rightly. But it don't give the right hint of member funtions , and a varialbe of string type it give a hint that is a int type.
if there is any setting and step I omit please instruct me .
Below is a part info of LSP messagesCodeLSP diagnostics: main.cpp|:|----Time: 15:16:19.218---- (5 diagnostics)|
E:\workspace\testcode\test1\HelloMingw64\main.cpp|1|note:'iostream' file not found|
E:\workspace\testcode\test1\HelloMingw64\main.cpp|8|warning:Using directive refers to implicitly-defined namespace 'std'|
E:\workspace\testcode\test1\HelloMingw64\main.cpp|12|note:Unknown type name 'string'|
E:\workspace\testcode\test1\HelloMingw64\main.cpp|25|note:Use of undeclared identifier 'cout'|
E:\workspace\testcode\test1\HelloMingw64\main.cpp|25|note:Use of undeclared identifier 'endl'|
LSP diagnostics: Test1.h|:|----Time: 15:16:20.533---- (0 diagnostics)|
LSP diagnostics: Test.h|:|----Time: 15:16:21.815---- (0 diagnostics)|
LSP diagnostics: Test.cpp|:|----Time: 15:16:22.844---- (4 diagnostics)|
E:\workspace\testcode\test1\HelloMingw64\src\Test.cpp|2|note:'iostream' file not found|
E:\workspace\testcode\test1\HelloMingw64\src\Test.cpp|4|warning:Using directive refers to implicitly-defined namespace 'std'|
E:\workspace\testcode\test1\HelloMingw64\src\Test.cpp|18|note:Use of undeclared identifier 'cout'|
E:\workspace\testcode\test1\HelloMingw64\src\Test.cpp|18|note:Use of undeclared identifier 'endl'|
LSP diagnostics: main.cpp|:|----Time: 15:19:41.802---- (5 diagnostics)|
E:\workspace\testcode\test1\HelloMingw64\main.cpp|1|note:'iostream' file not found|
E:\workspace\testcode\test1\HelloMingw64\main.cpp|8|warning:Using directive refers to implicitly-defined namespace 'std'|
E:\workspace\testcode\test1\HelloMingw64\main.cpp|12|note:Unknown type name 'string'|
E:\workspace\testcode\test1\HelloMingw64\main.cpp|26|note:Use of undeclared identifier 'cout'|
E:\workspace\testcode\test1\HelloMingw64\main.cpp|26|note:Use of undeclared identifier 'endl'|
LSP diagnostics: main.cpp|:|----Time: 15:19:51.121---- (12 diagnostics)|
......
......
@ myztmyI've been struggling with "clangd" for a whole day!
In order to be precise, we'll need you to paste your source code here between code tags. Paste the main.cpp code in your response using the "#" icon above the face icons. For example the "#" icon produces code tags that look like this:
[ code ] your main.cpp source[/ code ] (without the spaces around "code".
The "#" icon and face icons appear when you click on the "Reply" or "Quote" buttons.
I see that there are enough compile errors and warnings that it would confuse clangd. I think you're missing some #include statements. But we need to see your code first.
Regards
I've been struggling with "clangd" for a whole day!
With another win7 machine I install "GCC 13.1.0 (with POSIX threads) + LLVM/Clang/LLD/LLDB 16.0.5 + MinGW-w64 11.0.0 (UCRT) - release 5" which Clang and Mingw are in the same bin directory . This time , "clangd" can find the standard lib header files , add a string type variable it can identify the correct type and give the right hint. But it just made me happy for a few seconds. After using class wizzard add a simple class , clangd don't konw the new class and then don't give correct hint ,everything has become a mess again.
Go back to my MinGW-w64 and LLVM separate installation win7 machine , I try to throw clangd.exe into MinGW-w64 bin directory , the C::B always Pop up dialog box complain "can't dectect clangd.exe" . Placing clangd.exe in any other directory is no problem. In this machine clangd although can find user class but can't find standard lib class, also not working properly.
Most of the existing bugs now of "clangd" also existed in "Code completion" of C::B(win) 20.03 release , but the latest nightly builds version have fixed "Code completion" almost all bugs except freeze (I only have used C::B for ten days, and only tested those two C::B versions ). "clangd" seems like "Yesterday Once More" . I guess "clangd" has referenced some code from "Code completion" of older versions.
Now that you mention "#", let me show you a "funny" image(I really know what you mean ,but the imge explains everything, I don't think I need use "#" icon to post my so simplest source code :P ).
Regards
Since you will not provide us with your code in a form that we can copy and paste in order to re-create the errors, I'm going to step away from this conversation.
clangd cannot correctly provide you with good information when your code is full of errors.
You will have to read the errors provided by clangd and correct your code before popup info is reliable.
Secondly, moving clangd into arbitrary folders is asking for trouble. The clangd_client plugin provides clangd server with both the location of the clangd executable along with the location of its matching resources. Causing a miss match of these locations also causes clangd to issue incorrect info.
Good luck.
//main.cpp
#include <iostream>
#include "test.h"
using namespace std;
int main()
{
test t;
t.SetCounter(100);
t.GetCounter();
cout << "Hello world!" << endl;
return 0;
}
#ifndef TEST_H
#define TEST_H
class test
{
public:
test();
virtual ~test();
unsigned int GetCounter();
void SetCounter(unsigned int val);
protected:
private:
unsigned int m_Counter;
};
#endif // TEST_H
#include "test.h"
test::test()
{
//ctor
}
test::~test()
{
//dtor
}
unsigned int test::GetCounter() { return m_Counter; }
void test::SetCounter(unsigned int val) { m_Counter = val; }
obj.
Error occurred on Monday, September 25, 2023 at 16:09:47.
codeblocks.exe caused an Access Violation at location 00007FFCB25577DC in module codeblocks.dll Reading from location 0000000000000268.
AddrPC Params
00007FFCB25577DC 0000000000000000 0000000000000001 00000278CB581EA0 codeblocks.dll!ConfigManager::GetUserDataFolder+0x3ae3c
00007FFCB24F8A90 0000000000000000 00007FFCB29659C8 000000000000000A codeblocks.dll!sqstd_rex_getsubexp+0x1cb46
00007FFCB239C42D 00000278CB38D210 000000B6F77FD880 00000000FFFFFFFF codeblocks.dll!wxScintilla::GetLibraryVersionInfo+0x9ddb
00007FFCB239C7A4 00000278CB38D210 00000278CD41A040 00000278CB96700D codeblocks.dll!wxScintilla::GetLibraryVersionInfo+0xa152
00007FFCB248EEF2 00000278CB8AC840 00000278CD41A040 00000278CB8AC020 codeblocks.dll!wxScintilla::GetLibraryVersionInfo+0xfc8a0
00007FFCB248389A 00000278CB8AC020 0000000000000000 00000278CD41A040 codeblocks.dll!wxScintilla::GetLibraryVersionInfo+0xf1248
00007FFCB2485CBB 00000278CB8AC020 00007FFC00000834 0000000000000000 codeblocks.dll!wxScintilla::GetLibraryVersionInfo+0xf3669
00007FFCB23A1018 00000278CB8AC020 00007FFC00000834 0000000000000000 codeblocks.dll!wxScintilla::GetLibraryVersionInfo+0xe9c6
00007FFCB2384527 00000278C781B070 000000B600000834 0000000000000000 codeblocks.dll!wxScintilla::SendMsg+0x51
00007FFCB2386F4A 00000278C781B070 0000000000000000 000000B6F77FE2E0 codeblocks.dll!wxScintilla::AutoCompShow+0x52
00007FFCB22585AE 00000278C7476900 000000B6F77FE780 000000B6F77FE7D0 codeblocks.dll!CCManager::OnCompleteCode+0x86a
00007FFCB2552D79 00000278C7445450 000000B6F77FE780 000000B6F77FE890 codeblocks.dll!ConfigManager::GetUserDataFolder+0x363d9
00007FFCB22F4BE1 00000278C3000F00 000000B6F77FE780 000000B600000000 codeblocks.dll!Manager::ProcessEvent+0xb9
00007FFCB3F21EEB 00000278C5FBF4D0 00000278C6A1E4E0 00007FFCB40FFFD0 clangd_client.dll!0xa1eeb
00007FFCB3EB9610 00000278C3806840 00000278C6A1E4E0 0000000000000226 clangd_client.dll!0x39610
00007FFCB28C2E77 00000278C3806840 00007FFCB28C2E77 000000B6F77FF570 wxmsw32u_gcc_cb.dll!wxAppConsoleBase::CallEventHandler+0xb7
00007FFCB2A12AC5 00000278C349A120 00007FFCB2A13363 000000B6F77FF710 wxmsw32u_gcc_cb.dll!wxEvtHandler::ProcessEventIfMatchesId+0x85
00007FFCB2A12F84 00000278C3582B30 00000278C750A460 00000278CB8E0800 wxmsw32u_gcc_cb.dll!wxEvtHandler::SearchDynamicEventTable+0xd4
00007FFCB2A132D2 00000278C74E5C68 0000000000000000 0000000000000000 wxmsw32u_gcc_cb.dll!wxEvtHandler::TryHereOnly+0x22
00007FFCB2A12D93 00000278CB30C610 00000278CB30C610 00000278CB30C610 wxmsw32u_gcc_cb.dll!wxEvtHandler::DoTryChain+0x43
00007FFCB2A13441 0000000000000000 00007FFCF3CF5BA1 00000278C74E5C30 wxmsw32u_gcc_cb.dll!wxEvtHandler::ProcessEvent+0xc1
00007FFCB2A143E0 00000278CB309850 0000000000000000 00000278C2B1D880 wxmsw32u_gcc_cb.dll!wxEvtHandler::ProcessPendingEvents+0x110
00007FFCB28C45AA 0000000000000000 00007F0000010000 00000278C750A460 wxmsw32u_gcc_cb.dll!wxAppConsoleBase::ProcessPendingEvents+0x7a
00007FFCB28F4794 0000000000000000 0000000000000040 0000000000000000 wxmsw32u_gcc_cb.dll!wxEventLoopManual::ProcessEvents+0x24
00007FFCB28F48B8 00000278C2B1D880 00000278C750A460 0000000000000000 wxmsw32u_gcc_cb.dll!wxEventLoopManual::DoRun+0xf8
00007FFCB28F4588 0000000000000048 00007FFCF20CB870 000000B6F77FF990 wxmsw32u_gcc_cb.dll!wxEventLoopBase::Run+0x58
00007FFCB28C5FE0 0000000200000030 00007FFCB3962B40 0000000000000000 wxmsw32u_gcc_cb.dll!wxAppConsoleBase::MainLoop+0x70
00007FF78C045E94 00000278C2B1D880 00007FFCB2A1FAAF 00000278C1032528 codeblocks.exe!0x5e94
00007FFCB2938EB1 FFFFFFFFFFFFFFFF 0000000000000006 0000000000000048 wxmsw32u_gcc_cb.dll!wxEntryReal+0x51
00007FF78C0424A5 00007FF78C040000 0000000000000000 00000278C1033762 codeblocks.exe!0x24a5
00007FF78C0412EE 0000000000000000 0000000000000000 0000000000000000 codeblocks.exe!0x12ee
00007FF78C0413E6 0000000000000000 0000000000000000 0000000000000000 codeblocks.exe!0x13e6
00007FFCF20A7604 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk+0x14
00007FFCF3D226A1 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart+0x21
I see an alert when I enabled the Clangd_client, and when I hit the dot after I type an object name.Could you copy the Clangd_client from devel32_64 to output32_64 and see if you get the crash again.
Well, another question is:
In the suggestion list, does it need an icon for each item?
Here is the screen shot of mine, it looks like I just only have texts in the suggestion list after I press the "dot", see image shot below:
OK, I will do that. Thanks.I see an alert when I enabled the Clangd_client, and when I hit the dot after I type an object name.Could you copy the Clangd_client from devel32_64 to output32_64 and see if you get the crash again.
This will give us a line number.
The .RPT is useless without a line number.
Also, can you give an example code so I can reproduce the error.
I can't reproduce it yet.
Well, another question is:
In the suggestion list, does it need an icon for each item?
Here is the screen shot of mine, it looks like I just only have texts in the suggestion list after I press the "dot", see image shot below:
This looks like the .zip resources are missing. The images are in the .zip file. I just don't use them.
We've been using clangd_client for a year or more without icons.
I'd rather not use them if we don't have to.
The assert says that it occured at platwx.cpp 2582. There's no code there.
You might consider rebuilding CodeBlocks and contribs again.
void ListBoxImpl::Append(const wxString& text, int type) {
long count = GETLB(wid)->GetItemCount();
long itemID = GETLB(wid)->InsertItem(count, wxEmptyString);
long idx = -1;
GETLB(wid)->SetItem(itemID, 1, text);
maxStrWidth = wxMax(maxStrWidth, text.length());
if (type != -1) {
wxCHECK_RET(imgTypeMap, wxT("Unexpected NULL imgTypeMap"));
idx = imgTypeMap->Item(type);
}
GETLB(wid)->SetItemImage(itemID, idx, idx);
}
diff --git a/src/sdk/wxscintilla/src/PlatWX.cpp b/src/sdk/wxscintilla/src/PlatWX.cpp
index 247b558c..66d64375 100644
--- a/src/sdk/wxscintilla/src/PlatWX.cpp
+++ b/src/sdk/wxscintilla/src/PlatWX.cpp
@@ -198,7 +198,30 @@ void Font::Create(const FontParameters &fp) {
false,
sci2wx(fp.faceName),
encoding);
+
+#ifdef __WXMSW__
+ // enable the smooth font on Windows by default
+ // font rendering issue when using C::B under windows remote desktop
+ // https://forums.codeblocks.org/index.php/topic,25146.msg171484.html#msg171484
+
+ wxString nativeDesc = font.GetNativeFontInfoDesc();
+ int index = 0;
+ for (size_t pos = 0, start = 0; pos <= nativeDesc.length(); )
+ {
+ pos = nativeDesc.find(";", start);
+ index++;
+ if (index == 14) // the index 14 for wx 3.2.1
+ {
+ // enable the cleartype option of the font
+ nativeDesc.replace(start, pos - start, "5");
+ bool result = font.SetNativeFontInfo(nativeDesc);
+ break;
+ }
+ start = pos+1;
+ }
+#endif // __WXMSW__
wxFontWithAscent* newFont = new wxFontWithAscent(font);
+
fid = newFont;
#ifdef HAVE_DIRECTWRITE_TECHNOLOGY
Oh, thanks for the help. I looked at my local commits, and this is the only change I made to PlatWX.cpp, which I try to enable the font smooth. I don't have other changes to scintilla related code.Codediff --git a/src/sdk/wxscintilla/src/PlatWX.cpp b/src/sdk/wxscintilla/src/PlatWX.cpp
index 247b558c..66d64375 100644
--- a/src/sdk/wxscintilla/src/PlatWX.cpp
+++ b/src/sdk/wxscintilla/src/PlatWX.cpp
@@ -198,7 +198,30 @@ void Font::Create(const FontParameters &fp) {
false,
sci2wx(fp.faceName),
encoding);
+
+#ifdef __WXMSW__
+ // enable the smooth font on Windows by default
+ // font rendering issue when using C::B under windows remote desktop
+ // https://forums.codeblocks.org/index.php/topic,25146.msg171484.html#msg171484
+
+ wxString nativeDesc = font.GetNativeFontInfoDesc();
+ int index = 0;
+ for (size_t pos = 0, start = 0; pos <= nativeDesc.length(); )
+ {
+ pos = nativeDesc.find(";", start);
+ index++;
+ if (index == 14) // the index 14 for wx 3.2.1
+ {
+ // enable the cleartype option of the font
+ nativeDesc.replace(start, pos - start, "5");
+ bool result = font.SetNativeFontInfo(nativeDesc);
+ break;
+ }
+ start = pos+1;
+ }
+#endif // __WXMSW__
wxFontWithAscent* newFont = new wxFontWithAscent(font);
+
fid = newFont;
#ifdef HAVE_DIRECTWRITE_TECHNOLOGY
I see an issue which I guess it comes from the BrowseTracker plugin when using Clangd_Client plugin.
When I right click on a symbol(such as a function name), and select "goto definition" in the context menu, the Clangd_Client plugin did bring me to the function definition, that's good.
But when I click the toolbar(the toolbar from BrowseTracker plugin) Jump back, it does not go back to the place where I did the right click. I have to click the Jump back button several times to go back to the original place.
Do you guys see such issue?
Thanks.
I see an issue which I guess it comes from the BrowseTracker plugin when using Clangd_Client plugin.
When I right click on a symbol(such as a function name), and select "goto definition" in the context menu, the Clangd_Client plugin did bring me to the function definition, that's good.
But when I click the toolbar(the toolbar from BrowseTracker plugin) Jump back, it does not go back to the place where I did the right click. I have to click the Jump back button several times to go back to the original place.
Do you guys see such issue?
Thanks.
Index: JumpTracker.cpp
===================================================================
--- JumpTracker.cpp (revision 13374)
+++ JumpTracker.cpp (working copy)
@@ -458,6 +458,11 @@
void JumpTracker::OnEditorActivated(CodeBlocksEvent& event)
// ----------------------------------------------------------------------------
{
+ // This is causing the new activated editor to enter it's current line location //(ph 2023/10/22)
+ // before entering the clangd_client target of "Find declaration" causing the next
+ // jump back to jump to an out of sequence location.
+ return; //(ph 2023/10/23)
+
// Record this activation event and place activation in history
// NB: Editor Activated is not called on project loading.
// So we miss the first activated editor
@ ollydbg
Would you place the following "return;" mod in JumpTracker.cpp and see if it solves this problem for you.CodeIndex: JumpTracker.cpp
===================================================================
--- JumpTracker.cpp (revision 13374)
+++ JumpTracker.cpp (working copy)
@@ -458,6 +458,11 @@
void JumpTracker::OnEditorActivated(CodeBlocksEvent& event)
// ----------------------------------------------------------------------------
{
+ // This is causing the new activated editor to enter it's current line location //(ph 2023/10/22)
+ // before entering the clangd_client target of "Find declaration" causing the next
+ // jump back to jump to an out of sequence location.
+ return; //(ph 2023/10/23)
+
// Record this activation event and place activation in history
// NB: Editor Activated is not called on project loading.
// So we miss the first activated editor
The point of this test is to stop OnEditorActivated() from entering the current location of the activated editor before BrowseTracker gets to enters the location of the Clangd_client response.
Thanks, I just tested your patch, and it solved my reported jump issue, that's great!Fix applied 2023/10/24 for BrowseTracker head rev 13378
Thanks, I just tested your patch, and it solved my reported jump issue, that's great!Fix applied 2023/10/24 for BrowseTracker head rev 13378
The images are in the .zip file. I just don't use them.
We've been using clangd_client for a year or more without icons.
I'd rather not use them if we don't have to.
<snipped>
Neverthess, it could be nice if you could reintroduce those icons as it was in legacy codecompletion). For me, looking at the icons, quickly indicates if it's a variable or a method, also with the color, quickly indicates if it's public, private, protected... I have the feeling that some code are still there (in your codecompletion* or parsemanager*) but not activated by AddToImageList and GetImage(...) or code in comments.
May be, for those who don't like those icons, you could set a checkbox in the clangd plugin configuration.
Error occurred on Sunday, November 12, 2023 at 11:26:58.
codeblocks.exe caused an Access Violation at location 00007FF870B9D924 in module clangd_client.dll Reading from location FFFFFFFFFFFFFFFF.
AddrPC Params
00007FF870B9D924 000002A835C963F0 000002A83BBBD890 000002A836EDF8A0 clangd_client.dll!ClassBrowserBuilderThread::AddMembersOf+0x2cc [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 921]
00007FF870B9AABF 000002A835C963F0 0000000000000000 0000000000000000 clangd_client.dll!ClassBrowserBuilderThread::SelectGUIItem+0x2db [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 472]
00007FF870B99A7D 000002A835C963F0 0000000000000001 0000000000000000 clangd_client.dll!ClassBrowserBuilderThread::Entry+0x99 [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 309]
00007FF8782ECFBD 0000000000000000 000002A83653DCF0 000002A835C963F0 wxmsw32u_gcc_cb.dll!wxThreadInternal::DoThreadStart+0x64d
00007FF8782ED113 000002A83653C8D0 0000000000000000 000002A83653C8D0 wxmsw32u_gcc_cb.dll!wxThreadInternal::WinThreadStart+0x43
00007FF8CC66AF5A 00007FF8CC6C06D0 000002A83653C8D0 0000000000000000 msvcrt.dll!_beginthreadex+0x12a
00007FF8CC66B02C 0000000000000000 0000000000000000 0000000000000000 msvcrt.dll!_endthreadex+0xac
00007FF8CC0F7344 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk+0x14
00007FF8CD5C26B1 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart+0x21
Today, I got a crash when I'm editing in C::B, see the call stack here, (from the codeblocks.RPT file)CodeError occurred on Sunday, November 12, 2023 at 11:26:58.
codeblocks.exe caused an Access Violation at location 00007FF870B9D924 in module clangd_client.dll Reading from location FFFFFFFFFFFFFFFF.
AddrPC Params
00007FF870B9D924 000002A835C963F0 000002A83BBBD890 000002A836EDF8A0 clangd_client.dll!ClassBrowserBuilderThread::AddMembersOf+0x2cc [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 921]
00007FF870B9AABF 000002A835C963F0 0000000000000000 0000000000000000 clangd_client.dll!ClassBrowserBuilderThread::SelectGUIItem+0x2db [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 472]
00007FF870B99A7D 000002A835C963F0 0000000000000001 0000000000000000 clangd_client.dll!ClassBrowserBuilderThread::Entry+0x99 [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 309]
00007FF8782ECFBD 0000000000000000 000002A83653DCF0 000002A835C963F0 wxmsw32u_gcc_cb.dll!wxThreadInternal::DoThreadStart+0x64d
00007FF8782ED113 000002A83653C8D0 0000000000000000 000002A83653C8D0 wxmsw32u_gcc_cb.dll!wxThreadInternal::WinThreadStart+0x43
00007FF8CC66AF5A 00007FF8CC6C06D0 000002A83653C8D0 0000000000000000 msvcrt.dll!_beginthreadex+0x12a
00007FF8CC66B02C 0000000000000000 0000000000000000 0000000000000000 msvcrt.dll!_endthreadex+0xac
00007FF8CC0F7344 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk+0x14
00007FF8CD5C26B1 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart+0x21
It looks like a crash from the symbol tree building thread.
I'm using the clangd_client.dll without strip the debug information. And I'm using the rev 13384, I have some own patches, but my patches don't touch the symbol tree and thread handling related code.
Thanks.
Index: src/plugins/contrib/clangd_client/src/LSPclient/client.cpp
===================================================================
--- src/plugins/contrib/clangd_client/src/LSPclient/client.cpp (revision 13394)
+++ src/plugins/contrib/clangd_client/src/LSPclient/client.cpp (working copy)
@@ -427,11 +427,9 @@
wxString masterPath = pCompiler ? pCompiler->GetMasterPath() : "";
// get the first char of executable name from the compiler toolchain
- CompilerPrograms toolchain = pCompiler->GetPrograms();
- wxString toolchainCPP = toolchain.CPP.Length() ? wxString(toolchain.CPP[0]) : "";
+ const CompilerPrograms& toolchain = pCompiler->GetPrograms();
// " --query-driver=f:\\usr\\MinGW810_64seh\\**\\g*"
- wxString queryDriver = masterPath + fileSep + "**" + fileSep + toolchainCPP + "*";
- if (not platform::windows) queryDriver.Replace("\\","/");
+ wxString queryDriver = masterPath + fileSep + "bin" + fileSep + toolchain.CPP;
wxString pgmExec = clangd_Dir + fileSep + clangdexe;
QuoteStringIfNeeded(pgmExec);
Update to at least rev 13390.
I think this is already fixed.
Thanks for the report.
Error occurred on Tuesday, November 14, 2023 at 18:38:00.
codeblocks.exe caused an Access Violation at location 00007FF8733ED844 in module clangd_client.dll Reading from location FFFFFFFFFFFFFFFF.
AddrPC Params
00007FF8733ED844 000001B980D42BB0 000001B98611E480 000001B98175AC10 clangd_client.dll!ClassBrowserBuilderThread::AddMembersOf+0x2cc [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 921]
00007FF8733EA9DF 000001B980D42BB0 0000000000000000 0000000000000000 clangd_client.dll!ClassBrowserBuilderThread::SelectGUIItem+0x2db [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 472]
00007FF8733E999D 000001B980D42BB0 0000000000000001 0000000000000000 clangd_client.dll!ClassBrowserBuilderThread::Entry+0x99 [D:/code/cbsource/cb_svn_git/src/plugins/contrib/clangd_client/src/codecompletion/classbrowserbuilderthread.cpp @ 309]
00007FF876B7CFBD 0000000000000000 000001B980C88330 000001B980D42BB0 wxmsw32u_gcc_cb.dll!wxThreadInternal::DoThreadStart+0x64d
00007FF876B7D113 000001B980C877B0 0000000000000000 000001B980C877B0 wxmsw32u_gcc_cb.dll!wxThreadInternal::WinThreadStart+0x43
00007FF8CC66AF5A 00007FF8CC6C06D0 000001B980C877B0 0000000000000000 msvcrt.dll!_beginthreadex+0x12a
00007FF8CC66B02C 0000000000000000 0000000000000000 0000000000000000 msvcrt.dll!_endthreadex+0xac
00007FF8CC0F7344 0000000000000000 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk+0x14
00007FF8CD5C26B1 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart+0x21
if (data)
{
switch (data->m_SpecialFolder) // line 921 **************************
{
case sfGFuncs : AddChildrenOf(tree, node, -1, tkFunction, false); break;
case sfGVars : AddChildrenOf(tree, node, -1, tkVariable, false); break;
case sfPreproc : AddChildrenOf(tree, node, -1, tkMacroDef, false); break;
case sfTypedef : AddChildrenOf(tree, node, -1, tkTypedef, false); break;
case sfMacro : AddChildrenOf(tree, node, -1, tkMacroUse, false); break;
case sfToken:
{
Hi Pecan, I'm using a custom compiler for some projects. It is not recognised by clangd. If I change the code as below, it works fine and standard headers are parsed properly.CodeAs per the compiler settings, compiler binary should be present in <compiler path>/bin/ , so above change looks fine. But I'm afraid it could break some cases achieved by the original logic. Could you please help? I use Code::Blocks svn trunk on Ubuntu 18.04 wxwidgets 3.0 .Index: src/plugins/contrib/clangd_client/src/LSPclient/client.cpp
===================================================================
--- src/plugins/contrib/clangd_client/src/LSPclient/client.cpp (revision 13394)
+++ src/plugins/contrib/clangd_client/src/LSPclient/client.cpp (working copy)
@@ -427,11 +427,9 @@
wxString masterPath = pCompiler ? pCompiler->GetMasterPath() : "";
// get the first char of executable name from the compiler toolchain
- CompilerPrograms toolchain = pCompiler->GetPrograms();
- wxString toolchainCPP = toolchain.CPP.Length() ? wxString(toolchain.CPP[0]) : "";
+ const CompilerPrograms& toolchain = pCompiler->GetPrograms();
// " --query-driver=f:\\usr\\MinGW810_64seh\\**\\g*"
- wxString queryDriver = masterPath + fileSep + "**" + fileSep + toolchainCPP + "*";
- if (not platform::windows) queryDriver.Replace("\\","/");
+ wxString queryDriver = masterPath + fileSep + "bin" + fileSep + toolchain.CPP;
wxString pgmExec = clangd_Dir + fileSep + clangdexe;
QuoteStringIfNeeded(pgmExec);
Thanks, Christo
@ ollydbg
Are you running with Settings/Editor/Documentation Popup checked or unchecked?
If checked, uncheck it to see if the crashes go away.
I think I've found the cause, but I want to know if I'm in the ballpark.
@ ollydbg
Would you update to rev 13396 .
I found that LSP_ParseSemanticTokens could modify the TokenTree at the same time ClassBrowserBuildThread() was reading it.
After you run ./update32_64.bat, please copy the Clangd_client dll from Devel32_64 to output32_64 so that if it crashes we'll get the line numbers.
Remember to turn on Settings/Editor/Documentation popup checkbox.
Thanks
OK, I'll investigate. But after I find the reason for a ClassBrowser crash.
Hi, Pecan, thanks. I appreciate your work on the clangd_client plugin.I came across the post, and I wonder if you were able to implement what you wrote about?
I'm using the rev 13397 for about 6 hours, and I haven't see a crash here till now. :)
Hi, Pecan, thanks. I appreciate your work on the clangd_client plugin.I came across the post, and I wonder if you were able to implement what you wrote about?
I'm using the rev 13397 for about 6 hours, and I haven't see a crash here till now. :)
https://forums.codeblocks.org/index.php?topic=17543.0 (https://forums.codeblocks.org/index.php?topic=17543.0)
And I also wonder how much faster the clang_client works compared to the standard codecompletion (because my codecompletion in some cases does not see the classes, I changed the order of the included header files and disabled others, but there are still problems)?
The TU information is available to the user, for each activated (referenced) TU, about as fast as your cpu can run the Clangd parser. My Win10 system (an Intel i7/8 core) parses most TUs in 2 seconds or less. Giving Clangd more than 1 core makes for a speedy throughput since that allows Clangd to parse multiple TUs in parallel. I seldom have to wait for info.clangd use local network? If that's the case, then clang can't run faster than the native way.
The TU information is available to the user, for each activated (referenced) TU, about as fast as your cpu can run the Clangd parser. My Win10 system (an Intel i7/8 core) parses most TUs in 2 seconds or less. Giving Clangd more than 1 core makes for a speedy throughput since that allows Clangd to parse multiple TUs in parallel. I seldom have to wait for info.clangd use local network? If that's the case, then clang can't run faster than the native way.
Google gave a result in the search, to what extent do you agree with what is described there about the negative facts of clang use.
https://www.eclipsecon.org/sites/default/files/slides/EclipseCon2018-cpp-lsp_0.pdf
Hi, Pecan, thanks. I appreciate your work on the clangd_client plugin.I came across the post, and I wonder if you were able to implement what you wrote about?
I'm using the rev 13397 for about 6 hours, and I haven't see a crash here till now. :)
https://forums.codeblocks.org/index.php?topic=17543.0 (https://forums.codeblocks.org/index.php?topic=17543.0)
And I also wonder how much faster the clang_client works compared to the standard codecompletion (because my codecompletion in some cases does not see the classes, I changed the order of the included header files and disabled others, but there are still problems)?
ollydbg will have to answer your question about COW strings.
It applies to legacy CodeCompletion but not so much to Clangd_Cllient.
@ myztmy
Here's my compile of your source.
What's the problem you're presenting?
Please be aware that you have to correct the errors presented by clangd (in the LSP messages log) before clangd can give you proper analysis of your code.
Hi Pecan,
the issue he wanted to mention is that entering char # as described in the screenshot will offer in popup menu the class member method what make no sense in this location. But maybe I'm missing some idea?
I reproduced this issue.
Btw. I am unable to have working pre-processor code completion with clangd plugin from the beginning.
I'm not sure if it is nightly build intent, that not complete pre-processor statements or it is bug. I'm under latest windows 11.
In any case I'm forced to use auto launch typing 1 letter due missing prediction for shorter names than auto-launch in the code.
This is not really issue, but it is only mention.
In all the case very good work guys.
... quote snipped by pecan ....
Clangd Code Action (aka "fix available") is enabled from Head rev 13484.
Right-click any LSP log message containing "fix available" and select "Apply fix available" from the context menu.
Very strange ... This morning, after a new full rebuild, it works, no unhandled exception ! I cross my fingers.
gd_on
PS : my problem was apparently that I use my own version of cbp to build clang plugin. Normally, it is compatible with Pecan's one, except that I have no option -g and use -std=gnu++20 instead of -std=gnu++11.
If I restore those two options, as in Pecan's .cbp, it's OK.
Please tell me the version of gcc and clangd you're using so I can exactly mirror your evnvironment.It's the last versions from msys2 distribution, updated last week. gcc, clang ... in the same mingw64 directory.
note: I am using directly codeblocks.exe through a problem to setup color schemes using CbLauncherI don't understand what "problem to setup color schemes" means.
I have installed the 4 files specified in wiki manually in Clangd folder under Codeblocks and set the path in C/C++ parser tab.
LSP diagnostics: main.cpp|:|----Time: 19:49:39.185---- (4 diagnostics)|
C:\Users\tnadrchal\Documents\_Ostatni\C++\TESTS\_WORKING\TEST_CLANGD\TEST_CLANGD\main.cpp|1|error:In included file: 'bits/c++config.h' file not found|
C:\Users\tnadrchal\Documents\_Ostatni\C++\TESTS\_WORKING\TEST_CLANGD\TEST_CLANGD\main.cpp|5|error:No member named 'cout' in namespace 'std'|
C:\Users\tnadrchal\Documents\_Ostatni\C++\TESTS\_WORKING\TEST_CLANGD\TEST_CLANGD\main.cpp|5|error:No member named 'endl' in namespace 'std'|
C:\Users\tnadrchal\Documents\_Ostatni\C++\TESTS\_WORKING\TEST_CLANGD\TEST_CLANGD\main.cpp|1|warning:Included header iostream is not used directly (fix available) remove #include directive|
#include <iostream>
int main()
{
std::cout << "Test" << std::endl;
return 0;
}
Loaded config file 'C:\Users\tnadrchal\AppData\Roaming\CodeBlocks\default.conf' (personality: 'default')
Scanning for lexers in C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\share\codeblocks/lexers/...
Found 62 lexers
Loading lexer_A68k
Loading lexer_ada
Loading lexer_angelscript
Loading lexer_autotools
Loading lexer_bash
Loading lexer_batch
Loading lexer_bibtex
Loading lexer_caml
Loading lexer_cg
Loading lexer_cmake
Loading lexer_coffee
Loading lexer_cpp
Loading lexer_css
Loading lexer_cu
Loading lexer_d
Loading lexer_diff
Loading lexer_f77
Loading lexer_fortran
Loading lexer_glsl
Loading lexer_gm
Loading lexer_haskell
Loading lexer_hitasm
Loading lexer_html
Loading lexer_ihex
Loading lexer_inno
Loading lexer_java
Loading lexer_javascript
Loading lexer_latex
Loading lexer_lisp
Loading lexer_lua
Loading lexer_make
Loading lexer_markdown
Loading lexer_masm
Loading lexer_matlab
Loading lexer_nim
Loading lexer_nsis
Loading lexer_objc
Loading lexer_OgreCompositor
Loading lexer_OgreMaterial
Loading lexer_pascal
Loading lexer_perl
Loading lexer_plain
Loading lexer_po
Loading lexer_postscript
Loading lexer_powershell
Loading lexer_prg
Loading lexer_properties
Loading lexer_proto
Loading lexer_python
Loading lexer_rc
Loading lexer_registry
Loading lexer_ruby
Loading lexer_smalltalk
Loading lexer_sql
Loading lexer_squirrel
Loading lexer_srec
Loading lexer_tehex
Loading lexer_vbscript
Loading lexer_verilog
Loading lexer_vhdl
Loading lexer_xml
Loading lexer_yaml
Configured 0 tools
Scanning for plugins in C:\Users\tnadrchal\AppData\Roaming\CodeBlocks\share\codeblocks\plugins
Loaded 0 plugins
Scanning for plugins in C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\share\codeblocks\plugins
Tools Plus Plugin: Registering shell type Piped Process Control
Loaded 65 plugins
Loading:
Abbreviations
AStylePlugin
Autosave
AutoVersioning
BrowseTracker
BYOGames
CB_Koders
Cccc
clangd_client
ClassWizard
CodeSnippets
CodeStat
Compiler
copystrings
CppCheck
Cscope
Debugger
FilesExtensionHandler
DevPakUpdater
DoxyBlocks
cbDragScroll
EditorConfig
EditorTweaks
EnvVars
Exporter
FileManager
FortranProject
Scanning for lexers in C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\share\codeblocks/lexers/...
Found 62 lexers
Loading lexer_A68k
Loading lexer_ada
Loading lexer_angelscript
Loading lexer_autotools
Loading lexer_bash
Loading lexer_batch
Loading lexer_bibtex
Loading lexer_caml
Loading lexer_cg
Loading lexer_cmake
Loading lexer_coffee
Loading lexer_cpp
Loading lexer_css
Loading lexer_cu
Loading lexer_d
Loading lexer_diff
Loading lexer_f77
Loading lexer_fortran
Loading lexer_glsl
Loading lexer_gm
Loading lexer_haskell
Loading lexer_hitasm
Loading lexer_html
Loading lexer_ihex
Loading lexer_inno
Loading lexer_java
Loading lexer_javascript
Loading lexer_latex
Loading lexer_lisp
Loading lexer_lua
Loading lexer_make
Loading lexer_markdown
Loading lexer_masm
Loading lexer_matlab
Loading lexer_nim
Loading lexer_nsis
Loading lexer_objc
Loading lexer_OgreCompositor
Loading lexer_OgreMaterial
Loading lexer_pascal
Loading lexer_perl
Loading lexer_plain
Loading lexer_po
Loading lexer_postscript
Loading lexer_powershell
Loading lexer_prg
Loading lexer_properties
Loading lexer_proto
Loading lexer_python
Loading lexer_rc
Loading lexer_registry
Loading lexer_ruby
Loading lexer_smalltalk
Loading lexer_sql
Loading lexer_squirrel
Loading lexer_srec
Loading lexer_tehex
Loading lexer_vbscript
Loading lexer_verilog
Loading lexer_vhdl
Loading lexer_xml
Loading lexer_yaml
HeaderFixup
Header Guard
HelpPlugin
Help plugin ini file: C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\share\codeblocks\docs\index.ini
HexEditor
IncrementalSearch
cbKeyBinder
lib_finder
LogHacker
ModPoller
MouseSap
NassiShneidermanPlugin
OccurrencesHighlighting
OpenFilesList
Profiler
ProjectOptionsManipulator
ProjectsImporter
RegExTestbed
ReopenEditor
rndgen
ScriptedWizard
SmartIndentCpp
SmartIndentFortran
SmartIndentHDL
SmartIndentLua
SmartIndentPascal
SmartIndentPython
SmartIndentXML
SpellChecker
SymTab
ThreadSearch
tidycmt
ToDoList
ToolsPlus
wxSmith
wxSmithMime
wxSmithAui
wxSmithContribItems
WindowsXPLookNFeel
Initial scaling factor is 1.000 (actual: 1.000)
Running startup script
Script plugin registered: Find Broken Files plugin
Script/function 'edit_startup_script.script' registered under menu '&Settings/-Edit startup script'
ClangdClient: allocating ProxyProject (phase 1).
Opening C:\Users\tnadrchal\AppData\Roaming\CodeBlocks/CC_ProxyProject.cbp
Done.
ClangdClient: loading ProxyProject (phase 2.
Opening C:\Users\tnadrchal\AppData\Roaming\CodeBlocks/CC_ProxyProject.cbp
Done.
Parsing 0 files took 0 ms
SpellChecker: Thesaurus files 'C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\share\codeblocks\SpellChecker\th_en_US.idx' not found!
@ garwin
It looks like the problem is that neither Compiler nor Clangd_client can find the fully installed compiler.
How and where did you actually install (not copied) the mingw compiler?
How and where did you install (not copied) clangd?
Output file is bin\Debug\TEST_CLANGD.exe with size 70.53 KB
Process terminated with status 0 (0 minute(s), 1 second(s))
0 error(s), 0 warning(s) (0 minute(s), 1 second(s))
clangd --check=C:\Users\tnadrchal\Documents\_Ostatni\C++\TES
TS\_WORKING\TEST_CLANGD\TEST_CLANGD\main.cpp
C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\Clangd>clangd --check=C:\Users\tnadrchal\Documents\_Ostatni\C++\TES
TS\_WORKING\TEST_CLANGD\TEST_CLANGD\main.cpp
I[22:18:09.957] clangd version 18.1.1
I[22:18:09.960] Features: windows
I[22:18:09.960] PID: 24384
I[22:18:09.961] Working directory: C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\Clangd
I[22:18:09.962] argv[0]: clangd.exe
I[22:18:09.963] argv[1]: --check=C:\Users\tnadrchal\Documents\_Ostatni\C++\TESTS\_WORKING\TEST_CLANGD\TEST_CLANGD\main.cpp
I[22:18:09.973] Entering check mode (no LSP server)
I[22:18:09.974] Testing on source file C:\Users\tnadrchal\Documents\_Ostatni\C++\TESTS\_WORKING\TEST_CLANGD\TEST_CLANGD\main.cpp
I[22:18:09.978] Loading compilation database...
I[22:18:09.995] Loaded compilation database from C:\Users\tnadrchal\Documents\_Ostatni\C++\TESTS\_WORKING\TEST_CLANGD\TEST_CLANGD\compile_commands.json
I[22:18:10.001] Compile command from CDB is: [C:/Users/tnadrchal/Documents/_Ostatni/C++/TESTS/_WORKING/TEST_CLANGD/TEST_CLANGD] "C:\\Users\\tnadrchal\\Documents\\_Ostatni\\C++\\CodeBlocks\\Clangd\\g++.exe" --driver-mode=g++ -Wall -fexceptions -v -g "-IC:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include" "-IC:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include/c++" "-IC:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include/c++/13.1.0" "-IC:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32/13.1.0/include" "-IC:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32/13.1.0" "-IC:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32" -IC:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/Clangd/include -c -o obj/Debug/main.o "-resource-dir=C:\\Users\\tnadrchal\\Documents\\_Ostatni\\C++\\CodeBlocks\\lib\\clang\\18" -- "C:\\Users\\tnadrchal\\Documents\\_Ostatni\\C++\\TESTS\\_WORKING\\TEST_CLANGD\\TEST_CLANGD\\main.cpp"
I[22:18:10.005] Parsing command...
clang version 18.1.1
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\Clangd
I[22:18:10.030] internal (cc1) args are: -cc1 -triple x86_64-pc-windows-msvc19.33.0 -fsyntax-only -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name main.cpp -mrelocation-model pic -pic-level 2 -mframe-pointer=none -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -gno-column-info -gcodeview -debug-info-kind=constructor -fdebug-compilation-dir=C:/Users/tnadrchal/Documents/_Ostatni/C++/TESTS/_WORKING/TEST_CLANGD/TEST_CLANGD -v -fcoverage-compilation-dir=C:/Users/tnadrchal/Documents/_Ostatni/C++/TESTS/_WORKING/TEST_CLANGD/TEST_CLANGD -resource-dir "C:\\Users\\tnadrchal\\Documents\\_Ostatni\\C++\\CodeBlocks\\lib\\clang\\18" -I "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include" -I "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include/c++" -I "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include/c++/13.1.0" -I "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32/13.1.0/include" -I "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32/13.1.0" -I "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32" -I C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/Clangd/include -internal-isystem "C:\\Users\\tnadrchal\\Documents\\_Ostatni\\C++\\CodeBlocks\\lib\\clang\\18\\include" -internal-isystem "C:/Program Files/Microsoft Visual Studio 10.0/VC/include" -internal-isystem "C:/Program Files/Microsoft Visual Studio 9.0/VC/include" -internal-isystem "C:/Program Files/Microsoft Visual Studio 9.0/VC/PlatformSDK/Include" -internal-isystem "C:/Program Files/Microsoft Visual Studio 8/VC/include" -internal-isystem "C:/Program Files/Microsoft Visual Studio 8/VC/PlatformSDK/Include" -Wall -fdeprecated-macro -ferror-limit 19 -fmessage-length=120 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.33 -std=c++14 -fskip-odr-check-in-gmf -fdelayed-template-parsing -fcxx-exceptions -fexceptions -no-round-trip-args -faddrsig -x c++ "C:\\Users\\tnadrchal\\Documents\\_Ostatni\\C++\\TESTS\\_WORKING\\TEST_CLANGD\\TEST_CLANGD\\main.cpp"
I[22:18:10.034] Building preamble...
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/Clangd/include"
ignoring nonexistent directory "C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\lib\clang\18\include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 10.0/VC/include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 9.0/VC/include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 9.0/VC/PlatformSDK/Include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 8/VC/include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 8/VC/PlatformSDK/Include"
#include "..." search starts here:
#include <...> search starts here:
C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include
C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include/c++
C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include/c++/13.1.0
C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32/13.1.0/include
C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32/13.1.0
C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32
End of search list.
I[22:18:10.216] Built preamble of size 342244 for file C:\Users\tnadrchal\Documents\_Ostatni\C++\TESTS\_WORKING\TEST_CLANGD\TEST_CLANGD\main.cpp version null in 0.18 seconds
I[22:18:10.219] Indexing headers...
E[22:18:10.228] [pp_file_not_found] Line 1: in included file: 'bits/c++config.h' file not found
I[22:18:10.230] Building AST...
clang version 18.1.1
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\Clangd
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include"
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include/c++"
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include/c++/13.1.0"
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32/13.1.0/include"
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32/13.1.0"
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32"
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/Clangd/include"
ignoring nonexistent directory "C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\lib\clang\18\include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 10.0/VC/include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 9.0/VC/include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 9.0/VC/PlatformSDK/Include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 8/VC/include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 8/VC/PlatformSDK/Include"
#include "..." search starts here:
End of search list.
clang version 18.1.1
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\Clangd
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include"
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include/c++"
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include/c++/13.1.0"
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32/13.1.0/include"
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32/13.1.0"
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32"
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/Clangd/include"
ignoring nonexistent directory "C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\lib\clang\18\include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 10.0/VC/include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 9.0/VC/include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 9.0/VC/PlatformSDK/Include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 8/VC/include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 8/VC/PlatformSDK/Include"
#include "..." search starts here:
End of search list.
ignoring nonexistent directory "C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/Clangd/include"
ignoring nonexistent directory "C:\Users\tnadrchal\Documents\_Ostatni\C++\CodeBlocks\lib\clang\18\include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 10.0/VC/include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 9.0/VC/include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 9.0/VC/PlatformSDK/Include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 8/VC/include"
ignoring nonexistent directory "C:/Program Files/Microsoft Visual Studio 8/VC/PlatformSDK/Include"
#include "..." search starts here:
#include <...> search starts here:
C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include
C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include/c++
C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/include/c++/13.1.0
C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32/13.1.0/include
C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32/13.1.0
C:/Users/tnadrchal/Documents/_Ostatni/C++/CodeBlocks/MinGW 13.1/lib/gcc/x86_64-w64-mingw32
End of search list.
E[22:18:10.272] [no_member] Line 5: no member named 'cout' in namespace 'std'
E[22:18:10.273] [no_member] Line 5: no member named 'endl' in namespace 'std'
I[22:18:10.274] Indexing AST...
I[22:18:10.274] Building inlay hints
I[22:18:10.275] Building semantic highlighting
I[22:18:10.275] Testing features at each token (may be slow in large files)
I[22:18:10.278] All checks completed, 3 errors
@garwin
Remove the space(s) in"....mingw 13.1/....
On Windows 11 opening the project file itself in Windows (not directly through Codeblocks) does not parse the project on opening. Reparsing is needed to be done manually. Doing so through Codeblocks works fine.
Steps to reproduce:
1. Codeblocks not running
2. Double-click on any project file *.cbp
On Plugin wiki https://wiki.codeblocks.org/index.php/CB_Clangd_Client (https://wiki.codeblocks.org/index.php/CB_Clangd_Client) the first link to the plugin repository page is not working.
For information, there is a discussion of doxygen support for Clangd - https://github.com/clangd/clangd/issues/529 (https://github.com/clangd/clangd/issues/529)
diff --git a/src/plugins/contrib/clangd_client/src/LSPclient/lspdiagresultslog.cpp b/src/plugins/contrib/clangd_client/src/LSPclient/lspdiagresultslog.cpp
index b64e7d760..425268724 100644
--- a/src/plugins/contrib/clangd_client/src/LSPclient/lspdiagresultslog.cpp
+++ b/src/plugins/contrib/clangd_client/src/LSPclient/lspdiagresultslog.cpp
@@ -256,7 +256,7 @@ void LSPDiagnosticsResultsLog::OnApplyFixIfAvailable(wxCommandEvent& event) //(p
{
// Got the selected item index
selectedLineText = GetItemAsText(itemIndex);
- if (not selectedLineText.Contains(" (fix available) "))
+ if (not (selectedLineText.Contains(" (fix available) ") or (selectedLineText.Contains("(fixes available)"))))
{
wxString msg = wxString::Format(_("No Fix available for logLine(%d)"), int(itemIndex) );
InfoWindow::Display(_("NO fix"), msg);
diff --git a/src/plugins/contrib/clangd_client/src/codecompletion/parser/parser.cpp b/src/plugins/contrib/clangd_client/src/codecompletion/parser/parser.cpp
index b97e46a30..2ef369352 100644
--- a/src/plugins/contrib/clangd_client/src/codecompletion/parser/parser.cpp
+++ b/src/plugins/contrib/clangd_client/src/codecompletion/parser/parser.cpp
@@ -3688,15 +3688,17 @@ void Parser::OnRequestCodeActionApply(wxCommandEvent& event) //(ph 2024/02/12)
int startLine; // 1 origin; needs to be changed to zero origin
int lineStartCol;
int lineEndCol;
+ int endLine;
codeActionStr = FixesFound[ii];
try {
// std::string testData = "{\"newText\":\"int\",\"range\":{\"end\":{\"character\":8,\"line\":275},\"start\":{\"character\":4,\"line\":275}}}"; // **Debugging**
nlohmann::json jCodeAction = nlohmann::json::parse(codeActionStr.ToStdString());
newText = jCodeAction["newText"].get<std::string>();
- startLine = lineNumInt; // it's already 1 origin
+ startLine = jCodeAction["range"]["start"]["line"] ;
lineStartCol = jCodeAction["range"]["start"]["character"] ;
lineEndCol = jCodeAction["range"]["end"]["character"] ;
+ endLine = jCodeAction["range"]["end"]["line"] ;
}
catch(std::exception &err)
{
@@ -3708,9 +3710,12 @@ void Parser::OnRequestCodeActionApply(wxCommandEvent& event) //(ph 2024/02/12)
// pEd contains the cbEditor ptr from above
cbStyledTextCtrl* pControl = pEd->GetControl();
// Replace text; note that the startLine is from the log msg line, so it's 1 origin
- int linePosn = pControl->PositionFromLine(startLine-1); // use zero origin for line
- pControl->SetTargetStart(linePosn + lineStartCol);
- pControl->SetTargetEnd(linePosn + lineEndCol );
+ int linePosn = pControl->PositionFromLine(startLine); // use zero origin for line
+ int targetStart = linePosn + lineStartCol;
+ pControl->SetTargetStart(targetStart);
+ int lineEndPosn = pControl->PositionFromLine(endLine);
+ int targetEnd = lineEndPosn + lineEndCol;
+ pControl->SetTargetEnd(targetEnd);
pControl->ReplaceTarget(newText);
}//endfor FixesFound
Hi Pecan,
I found two issues with applying fix in my setup. I'm using clangd version 18.0.0
1. "fixes available" along with "fix available"
2. Multi line fixes, eg: unused header warnings.
Below modification helped to apply these fixes.Codediff --git a/src/plugins/contrib/clangd_client/src/LSPclient/lspdiagresultslog.cpp b/src/plugins/contrib/clangd_client/src/LSPclient/lspdiagresultslog.cpp
index b64e7d760..425268724 100644
--- a/src/plugins/contrib/clangd_client/src/LSPclient/lspdiagresultslog.cpp
+++ b/src/plugins/contrib/clangd_client/src/LSPclient/lspdiagresultslog.cpp
@@ -256,7 +256,7 @@ void LSPDiagnosticsResultsLog::OnApplyFixIfAvailable(wxCommandEvent& event) //(p
{
// Got the selected item index
selectedLineText = GetItemAsText(itemIndex);
- if (not selectedLineText.Contains(" (fix available) "))
+ if (not (selectedLineText.Contains(" (fix available) ") or (selectedLineText.Contains("(fixes available)"))))
{
wxString msg = wxString::Format(_("No Fix available for logLine(%d)"), int(itemIndex) );
InfoWindow::Display(_("NO fix"), msg);
diff --git a/src/plugins/contrib/clangd_client/src/codecompletion/parser/parser.cpp b/src/plugins/contrib/clangd_client/src/codecompletion/parser/parser.cpp
index b97e46a30..2ef369352 100644
--- a/src/plugins/contrib/clangd_client/src/codecompletion/parser/parser.cpp
+++ b/src/plugins/contrib/clangd_client/src/codecompletion/parser/parser.cpp
@@ -3688,15 +3688,17 @@ void Parser::OnRequestCodeActionApply(wxCommandEvent& event) //(ph 2024/02/12)
int startLine; // 1 origin; needs to be changed to zero origin
int lineStartCol;
int lineEndCol;
+ int endLine;
codeActionStr = FixesFound[ii];
try {
// std::string testData = "{\"newText\":\"int\",\"range\":{\"end\":{\"character\":8,\"line\":275},\"start\":{\"character\":4,\"line\":275}}}"; // **Debugging**
nlohmann::json jCodeAction = nlohmann::json::parse(codeActionStr.ToStdString());
newText = jCodeAction["newText"].get<std::string>();
- startLine = lineNumInt; // it's already 1 origin
+ startLine = jCodeAction["range"]["start"]["line"] ;
lineStartCol = jCodeAction["range"]["start"]["character"] ;
lineEndCol = jCodeAction["range"]["end"]["character"] ;
+ endLine = jCodeAction["range"]["end"]["line"] ;
}
catch(std::exception &err)
{
@@ -3708,9 +3710,12 @@ void Parser::OnRequestCodeActionApply(wxCommandEvent& event) //(ph 2024/02/12)
// pEd contains the cbEditor ptr from above
cbStyledTextCtrl* pControl = pEd->GetControl();
// Replace text; note that the startLine is from the log msg line, so it's 1 origin
- int linePosn = pControl->PositionFromLine(startLine-1); // use zero origin for line
- pControl->SetTargetStart(linePosn + lineStartCol);
- pControl->SetTargetEnd(linePosn + lineEndCol );
+ int linePosn = pControl->PositionFromLine(startLine); // use zero origin for line
+ int targetStart = linePosn + lineStartCol;
+ pControl->SetTargetStart(targetStart);
+ int lineEndPosn = pControl->PositionFromLine(endLine);
+ int targetEnd = lineEndPosn + lineEndCol;
+ pControl->SetTargetEnd(targetEnd);
pControl->ReplaceTarget(newText);
}//endfor FixesFound
Thanks, Christo
are you planning to introduce other patches by christo as :
https://forums.codeblocks.org/index.php/topic,25570.msg174618.html#msg174618 to mark warnings in yellow, errors still in red
and
https://forums.codeblocks.org/index.php/topic,25659.msg174619.html#msg174619 to show dignostics by clicking
I think the fisrt one is useful, but of course need to be updated
Thanks Pecan.
I face another issue now - regarding errors with fixes in different line, like errors due to missing includes, fix is not applied. It shows "No available fixes found" on applying. In Parser::OnRequestCodeActionApply() , there is a check if the fix is in same line that of the line causing the error. This might be causing the issue.
Thanks Pecan.
I face another issue now - regarding errors with fixes in different line, like errors due to missing includes, fix is not applied. It shows "No available fixes found" on applying. In Parser::OnRequestCodeActionApply() , there is a check if the fix is in same line that of the line causing the error. This might be causing the issue.
Can you give me a 1,2,3 list of a way to re-create the situation?
int main()
{
std::cout << "Hello";
return 0;
}
/home/christo/projects/Test/test2/main.cpp|3|error:Use of undeclared identifier 'std' (fix available) Include <iostream> for symbol std::cout|4. Right click and select "Apply fix if available"
Yes, I use Clangd 18 and got the same problem, too.
Thanks Pecan.
I face another issue now - regarding errors with fixes in different line, like errors due to missing includes, fix is not applied. It shows "No available fixes found" on applying. In Parser::OnRequestCodeActionApply() , there is a check if the fix is in same line that of the line causing the error. This might be causing the issue.
Fixed Head rev. 13494It works now, thank you Pecan for the quick response as always.
Thanks for the reports.
- "Find declaration of: ..." does not work for me.
- "Reparse this project" has become a must so that the menu entry "Find declaration of: ..." appears.
What is going wrong ?
OS : Windows 7 with SP1 x64
C::B : Nightly build 13496
clangd : 18.1.2
- "Find declaration of: ..." does not work for me.
- "Reparse this project" has become a must so that the menu entry "Find declaration of: ..." appears.
What is going wrong ?
OS : Windows 7 with SP1 x64
C::B : Nightly build 13496
clangd : 18.1.2
Not enough info.
Can you give us a simple example (code) to recreate the problem?
What steps can we perform to recreate the problem?
- "Find declaration of: ..." does not work for me.
- "Reparse this project" has become a must so that the menu entry "Find declaration of: ..." appears.
What is going wrong ?
OS : Windows 7 with SP1 x64
C::B : Nightly build 13496
clangd : 18.1.2
Not enough info.
Can you give us a simple example (code) to recreate the problem?
What steps can we perform to recreate the problem?
Here is my C::B project
Note that if I revert to using Code Completion back, then "Find declaration of: ..." starts working as expected.
The compiler I am using is: https://github.com/tomay3000/mingw-builds-binaries/releases/download/13.2.0-rt_v11-rev1/i686-13.2.0-release-posix-sjlj-ucrt-rt_v11-rev1.7z (https://github.com/tomay3000/mingw-builds-binaries/releases/download/13.2.0-rt_v11-rev1/i686-13.2.0-release-posix-sjlj-ucrt-rt_v11-rev1.7z)- "Find declaration of: ..." does not work for me.
- "Reparse this project" has become a must so that the menu entry "Find declaration of: ..." appears.
What is going wrong ?
OS : Windows 7 with SP1 x64
C::B : Nightly build 13496
clangd : 18.1.2
Not enough info.
Can you give us a simple example (code) to recreate the problem?
What steps can we perform to recreate the problem?
Here is my C::B project
Note that if I revert to using Code Completion back, then "Find declaration of: ..." starts working as expected.
@tomay3000
Thanks for providing the source.
Responses from Clangd are dependent on the symbols produced by the compiler being used.
Your project is using what looks like a 32 bit mingw compiler.
Where did you obtain that compiler so I can mirror your environment.
Using my default gcc 64 bit compiler gets a slew of compiler errors which means I won't get the same errors you do.
Also, what declaration are you trying to display so I can attempt to mimic the error.
Hello sir, I tried to install your plugin but the plugin gets disabling upon resart. I am following this https://wiki.codeblocks.org/index.php/CB_Clangd_Client#Windows:_Compiler_Clangd.2FLLVM_Package_Installer (https://wiki.codeblocks.org/index.php/CB_Clangd_Client#Windows:_Compiler_Clangd.2FLLVM_Package_Installer)guide.
I installed a nightly build of Code blocks, from 16th December 2023.
And downloaded,installed clang.exe with the following command: "pacman -S mingw-w64-clang-x86_64-clang-tools-extra".
And disabled the "code completion" plugin, then enabled "Clangd_Client".
Set my default compiler to clang.exe in code blocks compiler setting.
But after restarting code blocks, clangd_client remains disabled and there is no option of "clangd_client" on the left of editor settings.
I am not sure if following ONLY the "Configuring clangd_client" and "Windows: Compiler Clangd/LLVM Package Installer" section of the guide has led to this error or am I misinterpreting the instruction about setting a compiler before restarting.
A few questions so I can get a picture of your system setup.
1) Are you actually compiling with Clang.exe or with mingw64 or mingw32.
2) Do you work in 32 bit C++ or 64bit C++ ?
3) After installing the nightly, click on mainmenu/plugins/manage plugins.
Is clangd_client listed. See image below.
Is codecompletion disabled? Is clangd_client enabled?
Hello sir, I tried to install your plugin but the plugin gets disabling upon resart. I am following this https://wiki.codeblocks.org/index.php/CB_Clangd_Client#Windows:_Compiler_Clangd.2FLLVM_Package_Installer (https://wiki.codeblocks.org/index.php/CB_Clangd_Client#Windows:_Compiler_Clangd.2FLLVM_Package_Installer)guide.
I installed a nightly build of Code blocks, from 16th December 2023.
And downloaded,installed clang.exe with the following command: "pacman -S mingw-w64-clang-x86_64-clang-tools-extra".
And disabled the "code completion" plugin, then enabled "Clangd_Client".
Set my default compiler to clang.exe in code blocks compiler setting.
But after restarting code blocks, clangd_client remains disabled and there is no option of "clangd_client" on the left of editor settings.
I am not sure if following ONLY the "Configuring clangd_client" and "Windows: Compiler Clangd/LLVM Package Installer" section of the guide has led to this error or am I misinterpreting the instruction about setting a compiler before restarting.
A few questions so I can get a picture of your system setup.
1) Are you actually compiling with Clang.exe or with mingw64 or mingw32.
2) Do you work in 32 bit C++ or 64bit C++ ?
3) After installing the nightly, click on mainmenu/plugins/manage plugins.
Is clangd_client listed. See image below.
Is codecompletion disabled? Is clangd_client enabled?
1) My default compiler is mingw64
2) 64bit C++ (I use 64 bit version of everything whenever possible, just cuz of the paranoia that things might not work)
3) Yes it's same as displayed in the image
(about the nightly build, I haven't tried April 1st built yet.)
hmm. I haven't actually moved the compiler inside the code blocks folder(the one that I made for nightly build). will it have any effect?
(my compile is in, C:\msys64\mingw64\bin)
I Installed the April 1st build.
I disabled "Code_Completion" and than enabled "Clangd_Client".
closed Code Blocks. restarted it again.
open up plugin manager.
And see "Clangd_Client" is disabled.
Basically no difference
Important:
You have to use the clangd.exe under the mingw64 folder. Not the clang64 folder.
Using the wrong clangd.exe is what was causing all the diagnostic errors.
Your compiler is just fine where it is.
But for the time being lets use the one in the April 1 nightly so we both are in sync with each other.
You can change it later if you wish.
Your compiler is just fine where it is.
But for the time being lets use the one in the April 1 nightly so we both are in sync with each other.
You can change it later if you wish.
???
wait a minute. the zip file of the nightly build(from 1st April) that I downloaded didn't had any compiler in it, just a folder named "shared"
In the coming Nightly, you will also be able to Alt-LeftMouseClick on the red/green warning/error box in the margin to apply any suggested fix.Hmmm... I might have to keep an eye out for nightly build after this.
Hi,
I'm writing to submit a (passible) bug report of the Code Completion plugin (LSP and Clangd).
When I load a project the plugin starts to parse all the project's files. I observe the log of parsing in the Code::Blocks panel of the Logs window. In the meantime I open a file, Application.cpp for example, and I select "Application:" to use the plugin (see image attached)...but...as soon as a new file is parsed the selection disappears....so I can't use the code completion till the full parsing of the projects. As soon as a new file parsing is completed the selection becomes blank.
Is this behavior expected?
Windows 10 , latest nightly , latest Mys2 clang 18.1.3-1
Would you please give steps to re-create and trace the problem, i.e.,
1) do this
2) now do that
Hi,
I'm writing to submit a (passible) bug report of the Code Completion plugin (LSP and Clangd).
When I load a project the plugin starts to parse all the project's files. I observe the log of parsing in the Code::Blocks panel of the Logs window. In the meantime I open a file, Application.cpp for example, and I select "Application:" to use the plugin (see image attached)...but...as soon as a new file is parsed the selection disappears....so I can't use the code completion till the full parsing of the projects. As soon as a new file parsing is completed the selection becomes blank.
Is this behavior expected?
Windows 10 , latest nightly , latest Mys2 clang 18.1.3-1
It is only active when an editor has been activated. It shows the classes and the functions that the editors cursor is positioned within. I.e., the cursor must have clicked in an
editor at least once (activate) to fill in the choice boxes.
What's happening in your video is that you never activated the editor by clicking into it. So the choice boxes were never populated.
It is only active when an editor has been activated. It shows the classes and the functions that the editors cursor is positioned within. I.e., the cursor must have clicked in an
editor at least once (activate) to fill in the choice boxes.
What's happening in your video is that you never activated the editor by clicking into it. So the choice boxes were never populated.
Thank you for your answer but....
...it seems that the issue is still the same even if I'm clicking the editor.
Hereafter another video in which it should be very clear that I'm activating (clicking) the editor but the "left choice" still disapperar.
If I'm so quick (very quick) to select something in the "right choice" before the "left choice" is blanked .... then the "left choice" is no longer disappearing. But it's difficult...I need to be very quick. Basically I need to wait for the parsing completion before using the plugin.
https://drive.google.com/file/d/1ntVkrxRg9YccNJBByNuHaBKE-SgX3Xwn/view?usp=sharing
It is only active when an editor has been activated. It shows the classes and the functions that the editors cursor is positioned within. I.e., the cursor must have clicked in an
editor at least once (activate) to fill in the choice boxes.
What's happening in your video is that you never activated the editor by clicking into it. So the choice boxes were never populated.
Thank you for your answer but....
...it seems that the issue is still the same even if I'm clicking the editor.
Hereafter another video in which it should be very clear that I'm activating (clicking) the editor but the "left choice" still disapperar.
If I'm so quick (very quick) to select something in the "right choice" before the "left choice" is blanked .... then the "left choice" is no longer disappearing. But it's difficult...I need to be very quick. Basically I need to wait for the parsing completion before using the plugin.
https://drive.google.com/file/d/1ntVkrxRg9YccNJBByNuHaBKE-SgX3Xwn/view?usp=sharing
hey @Pecan
sorry to bother you again but I have encounter an unusual behavior.
I was trying to use a large single file libraryhttps://github.com/mackron/miniaudio (https://github.com/mackron/miniaudio).
It has a single headerfile: miniaudio.h <--- 62k lines
when I try to open the header file or search for declaration through the main.c, whole code blocks freezes for solid 1-2 mins, weanwhile the mouse gradually becomes unresponsive until it's completely frozen and the screen turns black. Throws an error that Clangd_Cliet has stopped at the end.
I not sure if it's because my laptop isn't powerful enough. because the plugin usually worked smooth with other large libraries.
Apart from this single instance the plugin works fine and it has been very helpful.
hey @Pecan
sorry to bother you again but I have encounter an unusual behavior.
I was trying to use a large single file libraryhttps://github.com/mackron/miniaudio (https://github.com/mackron/miniaudio).
It has a single headerfile: miniaudio.h <--- 62k lines
when I try to open the header file or search for declaration through the main.c, whole code blocks freezes for solid 1-2 mins, weanwhile the mouse gradually becomes unresponsive until it's completely frozen and the screen turns black. Throws an error that Clangd_Cliet has stopped at the end.
I not sure if it's because my laptop isn't powerful enough. because the plugin usually worked smooth with other large libraries.
Apart from this single instance the plugin works fine and it has been very helpful.
I'll have a look at it.
Please attach your .cbp file for the project and your main.c to a forum reply, so I can mirror what's happening.
Thanks for the report.
I see that you're not clicking either inside a class or a function.
Do this, after the clicked file has parsed, click inside a function, not at the top of an editor file.
I'll have a look at it.(sorry for the late reply, I lost track of time)
Please attach your .cbp file for the project and your main.c to a forum reply, so I can mirror what's happening.
Thanks for the report.
After testing and tracing clangd_client and the miniAudio source I believe it will not be possible to pass that 4meg miniAudio.h file to clangd.yea that makes sense I guess. I think I'll have to break the miniaudio.h in like miniaudio1.h miniaudio2.h miniaudio3.h... no?
I have a relatively fast system, but clangd never finished parsing the header file before it crashed attempting to create a response file which would have been many times the size of the source file (about 24meg or more) after it formatted a response containing line/col/symbol/diagnostics/fix suggestions, etc.
If it didn't give out of memory, it sure would have caused Clangd_client to.
That header file will have to be broken up into multiple headers in order for clangd to handle it.
Note from opinionated self: I really do not consider creating a 4meg header file as acceptable software design. It's just going to create grief for anyone using it. If not now, certainly in the future.
After testing and tracing clangd_client and the miniAudio source I believe it will not be possible to pass that 4meg miniAudio.h file to clangd.yea that makes sense I guess. I think I'll have to break the miniaudio.h in like miniaudio1.h miniaudio2.h miniaudio3.h... for the plugin to not crash, no?
I have a relatively fast system, but clangd never finished parsing the header file before it crashed attempting to create a response file which would have been many times the size of the source file (about 24meg or more) after it formatted a response containing line/col/symbol/diagnostics/fix suggestions, etc.
If it didn't give out of memory, it sure would have caused Clangd_client to.
That header file will have to be broken up into multiple headers in order for clangd to handle it.
Note from opinionated self: I really do not consider creating a 4meg header file as acceptable software design. It's just going to create grief for anyone using it. If not now, certainly in the future.
After testing and tracing clangd_client and the miniAudio source I believe it will not be possible to pass that 4meg miniAudio.h file to clangd.yea that makes sense I guess. I think I'll have to break the miniaudio.h in like miniaudio1.h miniaudio2.h miniaudio3.h... for the plugin to not crash, no?
I have a relatively fast system, but clangd never finished parsing the header file before it crashed attempting to create a response file which would have been many times the size of the source file (about 24meg or more) after it formatted a response containing line/col/symbol/diagnostics/fix suggestions, etc.
If it didn't give out of memory, it sure would have caused Clangd_client to.
That header file will have to be broken up into multiple headers in order for clangd to handle it.
Note from opinionated self: I really do not consider creating a 4meg header file as acceptable software design. It's just going to create grief for anyone using it. If not now, certainly in the future.
On Windows 11 opening the project file itself in Windows (not directly through Codeblocks) does not parse the project on opening. Reparsing is needed to be done manually. Doing so through Codeblocks works fine.Re: Fixed Clangd and parser not parsing when user cold starts CB via DDE. Commit rev 13515
Steps to reproduce:
1. Codeblocks not running
2. Double-click on any project file *.cbp
On Plugin wiki https://wiki.codeblocks.org/index.php/CB_Clangd_Client (https://wiki.codeblocks.org/index.php/CB_Clangd_Client) the first link to the plugin repository page is not working.
For information, there is a discussion of doxygen support for Clangd - https://github.com/clangd/clangd/issues/529 (https://github.com/clangd/clangd/issues/529)
src/plugins/contrib/clangd_client/src/LSPclient/lspdiagresultslog.cpp:97:12: error: invalid use of incomplete type 'class wxListCtrl'
svn13516 does not compile on my arch linux using wxWidgets trunk:Quotesrc/plugins/contrib/clangd_client/src/LSPclient/lspdiagresultslog.cpp:97:12: error: invalid use of incomplete type 'class wxListCtrl'
Probably a missing #include
Cheers
svn13517: - Clangd_client include "sdk.h" needed for lspdiagresultslog.cpp no matter what clangd says
#include <cmath> // IWYU pragma: keep
When debugging, the current PC (program counter) marker is covered by the clangd_client marker.
When debugging, the current PC (program counter) marker is covered by the clangd_client marker.
Fixed HEAD 13520
The clangd warning/error margin markers are remove when the debugger starts up.
@Pecan: Thank you.
@ollydbg: Maybe it is bit of motivation to change the code for good, so that clangd does not show markers anymore -- at least if it is your own code you are free to change. The smaller a marker is, the harder it is to hit it with the mouse. Alternatively one might consider toggling the markers somehow.
When debugging, the current PC (program counter) marker is covered by the clangd_client marker.
Fixed HEAD 13520
The clangd warning/error margin markers are remove when the debugger starts up.
Hi, pecan, thanks for the fix.
When I'm not debugging, I try to set some breakpoints, and I see the clangd's marker still covers the breakpoint's marker.
So, I think we still need to find a way to show both of the above mentioned markers.
EDIT:
Maybe, make the clangd_client's marker a big smaller?
meaningful workflow during editing/debugging should be the guide to visual appearance.
@ollydbg: What is your take on this? For how long do both markers compete for the spot in your projects? Do either markers last that long that it really matters?
I prefer Pecan's method "I can change it to a small right pointing arrow that fits inside any other marker".
I prefer Pecan's method "I can change it to a small right pointing arrow that fits inside any other marker".
Commit HEAD 13521:
Clangd_client warning margin marker changed to a small right pointing arrow.