I have developed a clangd CB plugin client using Language Server Protocol (LSP).
It's working well.
However, it requires clangd version 12 to work even better.
What is the CodeBlocks policy of distributing an executable, say, clangd.exe v12 with the usual CodeBlock distribution.
CodeLite also distributes clangd with its LSP plugin.
Request for Comments.
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).
Hi, Pecan, good work!
For me, I think distribute a clangd.dll is OK, or we can distribute a separate plugin package(include the plugin and the clangd.dll). Then the user can just download and unpack it.
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?
Quote from: oBFusCATed on February 20, 2021, 11:34:07 PM
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).
Using the LSP, I think at least code completion list will be more precise than the native CC.
Quote from: oBFusCATed on February 20, 2021, 11:33:10 PM
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.
Just detecting the installation and using its clangd does not work. I've already tried that. The llvm's versions up to version 8 have no reliable clangd for a CB plugin.
The clangd in llvm versions 8 through 11 are so different from version 12 that the plugin using them would require two separate plugins or spaghetti code to support them.
CB will have to pick some version between 10 through 12 and program towards that.
I've chosen to work with clangd v12. It can reload the compile commands database without having to kill/restart the LSP server when a user opens a new file.
Quote from: oBFusCATed on February 20, 2021, 11:34:07 PM
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).
Using LSP "workspace/publishDiagnostics" with clangd is working well for me. I'ts halved my development time. I no longer have to compile the code to find the errors. They're presented to me as I enter the code or save it.
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.
LSP/Clangd is primarily focused on the translation unit (TU). But its still possible to provide a bigger picture by asking for workspace symbols. I haven't tried that (yet).
Quote from: ollydbg on February 21, 2021, 01:24:00 AM
...<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>...
CodeLite allows the user to choose the clang to use, but it prioritizes using clangd v10, which it distributes in dir Runtime/lsp.
Later versions of clangd are very independent of llvm/clang. For example clangd v12 can use many llvm/clang versions.
I don't have a repository yet. Things are still very experimental. But I'll work on that.
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.
Quote from: Pecan on February 22, 2021, 05:27:11 PM
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.
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. :)
Quote from: oBFusCATed on February 22, 2021, 06:05:26 PM
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. :)
In the furture, I'm sure we can generalize to a LSP UI. For the time being, I'm coding a plugin to concentrate learning and experimentation. I'll be happy to name it clangd-lsp. That's a good name.
Good to know clangd v12 rc1 may be out in the summer. I don't expect this plugin will be ready to publish any sooner.
Do you have a public repo? I'm super interested in contributing to this plugin.
Quote from: Lazauya on May 02, 2021, 05:02:42 AM
Do you have a public repo? I'm super interested in contributing to this plugin.
I do not yet have a public repo.
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.
I'm working hard at it.
But thanks for the offer.
Quote from: Pecan on May 02, 2021, 06:34:47 AM
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.
I don't mind. I could definitely help in debugging, test writing, code cleaning, etc. This is the kind of thing I've been looking for, and I'd very much like to accelerate development of it as much as possible, if you would let me.
@ AndrewCot:
What is your concurrently processing threads set to at
Settings->clangd_client-> C/C++parser ->Concurrently parsing threads.
It might not be there. I don't know when I implementd that.
Clangd seems to need 3-4 seconds to index a 2-3k line file, but it's very fast at the user response level once a file is indexed
In the new implementation (not uploaded yet) I set clangd parsing the active editor first, then the other open editors, then recently modified files, then all the others.
That way, you do not have to wait to begin using clangd. Just open the editor you want to work in. It gets sent to the front of the line, and it's should be parsed and indexed in 3 or 4 seconds.
Clangd can parse, Goto (decls and defs), find references, rename symbols etc. etc. all at the same time. No need to wait. Just open the file.
You do not need to wait for files to parse like the older CodeCompletion. Just activate the file you want to work in. The non-opened files parse in another address space at their own pace. If you switch editors, clangd-client knows whether it's been parsed or not. If it hasn't been, it's send immediately to clangd which parses it ahead of any background files.
This works great as long as at least one clangd thread is available.
The trick I found was to set the clangd threads to no more than 1/2 of the system (cpu) threads (hard coded in client allocation). I've given clangd 4 threads of my i7's 8 , and set concurrent parsing threads to 2. That usually guarantees that a thread will be available for priority (active editor) parses. I'm able to compile, background parse, GoTo, Find references, code complete, show function, etc all at the same time.
My parsing times look 1/2 of yours.
What's your hardware look like? What cpu, how many threads?
But all of this will come to light with testing and discussion (as you are doing now). Thanks.
Go easy on me for a little longer. I'm running into problems.
Clangd is passing back 3 byte UTF8 chars during code completions, crashing json parses. I'm stalled trying to fix that. I found the culprit today, Hopefully I can fix it tomorrow .
Quote from: AndrewCot on January 07, 2022, 03:34:10 AM
@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.
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
@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. Even as it is now it's still a big improvement on the existing codecompletion code. The changes I have made are in the https://github.com/acotty/codeblocks_sf/tree/AC-WindowsInstaller branch if you need or want to look at what I have done.
My setup is:
Windows 10 21H2 with latest updates (checked last night and it was up to date)
32GB DDR4 3600Mhz ram (2x16gb sticks)
AMD Ryzen 7 5700G (8 core plus 8 HT for a total of 16, base 3800 Mhz boost 4650)
No separate GPU
C: & D: are on a Samsung SSD 980 pro.
MSYS2 MinGW64 GCC 11.2.0
C: has the MSYS 2 compiler on it.
D: has the CB and other source code on it.
I had 1 concurrent parsing thread setup, but changed this about 2 hours ago to 8 and it speed up the overall time, but the time shown per file was still about the same.
As for the UTF8 I have no idea, but will do some searching after dinner (OZ Sydney time).
Quote from: AndrewCot on January 07, 2022, 08:26:32 AM
@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...
I understand. And I really appreciate your doing all this work. I really need to set up some sort of bug tracking.
I'll work on it.
Thanks.
@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?
Below is my updated list of things (queries, potential to do items, work I did ) for the plugin
Queries I have:
1) What is the clangd_client toolbar for? It is greyed out when I enable it and neither drop down is populated/enabled.
Changes that still need to be done that I spotted are:
1) Fix one compiler warning left (when built as a core plugin):
src\plugins\clangd_client\src\LSPclient\lspdiagresultslog.cpp:10:25:
warning: .objs31_64\include/sdk_precomp.h.gch: not used because `EXPORT_LIB' not defined [-Winvalid-pch]
10 | #include "sdk_precomp.h"
2) Add support for building under Linux, Mac and Windows x64 & x86 as a core plugin.
3) Add plugin files to the Debain, Mac and windows installer scripts/process.
4) Test installers works and the plugin works after installing using installer
5) With r8 the setup requires you to specify the C:\msys64\clang64\bin\clangd.exe , not the direxctory it is in.
The wxwidget group text needs to change to match this change.
6) The LSP plugin column widths do not take up the full width of the lopg dialog on my FDH screen (1920 x 1080). The
other logs also have this issue, so it may not be easy to fix.
The changes done to incorporate plug as a core plugin follow that may/will need to be incorporated at some stage:
1. Included the SF src in the src\plugins\clangd_client directory (same level as the codecompletion core plugin)
2. Incorporate the windows cpb into the src\CodeBlocks_wx31_64.cbp with changes
3. Update code for use with PCH as per src\CodeBlocks_wx31_64.cbp (client.cpp and codecompletion.cpp changed)
4. Updated my unofficial NSIS installer to add the plugin
The following is what is needed to get the plugin working with MSYS2:
1) Install MSYS 2 clang packages:
pacman -S mingw-w64-clang-x86_64-toolchain
2) Configure for use:
a) In the Settings->editor select Clangd_Client settings.
b) In the C/C++ parser tab change the "LLVM directory" to specify the clangd.exe you have installed:
C:\msys64\clang64\bin\clangd.exe
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:
Ticket# Summary
1057 Code completion header search path disrespect build target/platform
1028 Tab Code Completion bug
859 "Implementation of" is searching in all projects instead of current one
820 "Find references of" doesn't always work
793 Code completion stop working with enum defined inside function body
790 Code Completion lacks cstdint typedefs when prefixed with std::
788 Code completion doesn't account for shared_ptr, unique_ptr, etc
716 Code::Blocks 17.12 CodeCompletion slows down the editor dramatically
692 Intellisense not working unless include paths provided plus CB slash auto-conversion in paths
679 Right-click on <header.h>: CB looks in GCC path first regardless of chosen compiler
576 Add case sensitivity for header/source search under case-sensitive systems
518 Source parser error (SVN 11087
498 Parsing of the doxygen comment "see also" command error
474 Autocompletion does not work by using const pointer
388 Code completition doesn't work if used C++11 raw string literal
298 Code completion only works in gcc projects
286 CC crash when closing workspace
283 Bug e Outros 15.xx Brasil C++ Previso Erros
281 Let's CC support Conditional Code :: Blocks. highlighting in the editor
237 CC will not show all members in the namespace std
236 No code completion in array-of-struct
224 Duplication in documentation tooltip
213 ParserThread::GetBaseArgs function need to be refactored
212 space in Tokenizer::ReadParentheses issue
197 thread safty issue of CodeCompletion plugin
193 running cctest is too slow
177 Code completion fails with enum variables defined/declared along with the enum types
172 code completion doesn-t work with auto key word
156 CC failed parsing the char (*varname)[7]; (a pointer to an array of characters) definition
145 Code completion ignores parameters of catch-clauses
127 Code completion fails with complex declarations/definitions
88 Code completion mouse hover tooltip is always active
83 codecompletion's setting not saved correctly
47 Show call tip of the constructor function
43 Code complete - keyword final
31 restrict keyword and auto-completion
159 Code Completion fails for C++ functions marked "override"
158 Code completion fails with the "using Alias = Type" syntax in C++11
33 C++11 Initializer lists fool code completion
211 CCTest for the parser logic
313 CB hangs when loading a project for the first time after new launch
256 CC's Toolbar does not show function correctly inside the namespace scope
312 CC's symbol tree does not show correctly unless collapse and expand again
438 Popup hint for std::vector::end() causes Codeblocks to freeze
311 C::B hangs when exits
Quote from: AndrewCot on January 09, 2022, 01:55:05 AM
@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?
Quote from: AndrewCot on January 09, 2022, 11:21:31 AM
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:
@AndrewCot
Damn !! Thanks for all this hard work.
I'll start working on this today.
I'm not sure right now, but I think I have to enable tickets user by user. I seem to remember a lot of ads showing up in the tickets if it's opened for everyone. I could be wrong.
Would you send me a private message with your SourceForge login ID. (not your password). I'll find a way to authorize you for tickets. (i"m still not very adept at "SorceForging".
I would suggest to add it to the opfficial Cb repo at location next to the current cc.
Quote from: Pecan on January 07, 2022, 08:06:13 AM
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
I'm not sure if i fully understand what you have written, but it seems you are mixing some things. UTF8 is a variable length encoding, while each of its code units is 8 bit, a valid encoding can be comprised of 1 to 6 code units. Such a sequence gets decoded to a 32 bit code point, which i think you refer to as character. Both your mentioned sequences above are totally valid UTF8.
i was curious what symbol it is:
https://www.compart.com/en/unicode/U+2026
ps.: I can not post the symbol here, it seems the forum software is not utf8 conform :)
A clangd_client plugin cbPlugin package is available for the 31 December nightly at:
https://sourceforge.net/projects/cb-clangd-client/files/
Download the clangd_client.cbplugin file.
In CodeBlocks MainMenu=>plugins=>Manage plugin=> disable CodeCompletion .
Navigate to the downloaded file (clangd_client_plugin.zip) and unzip it to a temporary folder.
Copy the clangd_client.zip file to the CodeBlocks nightly ...\share\CodeBlocks\ folder.
Copy the clangd_client.dll file to the CodeBlocks nightly ...\share\Codeblocks\plugins\ folder
Restart the nightly CodeBlocks.
To uninstall, delete the above files from the CodeBlocks Nightly folders.
If you uninstall it using the "Manage plugins" menu , a crash may occur if a workspace is active.
Close the workspace first before uninstalling to avoid the crash.
We'll apply a fix for that soonest.
If you previously installed the clangd_client.cbplugin version, delete it with the commands:
del %APPDATA%\CodeBlocks\share\codeblocks\plugins\clangd_client.dll
del %APPDATA%\CodeBlocks\share\codeblocks\clangd_client.zip
The .cbplugin version became entirely too invasive.
Thanks to AndrewCot.
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.
Quote from: AndrewCot on January 12, 2022, 06:52:25 AM
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.
There is a typo in the file: https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/0.2.5%20-%2012JAN2022/Windows-LLVM-ClangD-Install-Readme.txt/download
Quote
instructions below for the specific compiler you haev installed:
File in SVN has been updated, so the next update will include the typo fixed.
Quote from: AndrewCot on January 12, 2022, 12:20:11 PM
File in SVN has been updated, so the next update will include the typo fixed.
There is another typo:
QuoteWindows 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
You can see there are two "3)" sub-sections.
BTW:
I download the package: clangd_client.zip (https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/0.2.5%20-%2012JAN2022/clangd_client.zip/download), but when I try to "install" the plugin by the plugin manager, it need a file "*.cbplugin", while I see only this zip file, so I need to rename the file extension?
File clangd_client.zip is a mess, it contains two levels of older copies of itself.
You just need the DLL and a zip containing the resources.
I have just created a wiki entry for the .cbplugin file format: https://wiki.codeblocks.org/index.php/Code::Blocks_Plugins#Format_of_.cbplugin_files (https://wiki.codeblocks.org/index.php/Code::Blocks_Plugins#Format_of_.cbplugin_files)
It is a draft based on the source code, if somebody has more information or spots an error please edit it.
@ollydbg In the plugin manager you specify the zip file instead of a .cbplugin and it works
@Miguel Thanks for the info. I need mod the project file to check and delete the zip file otherwise you get the zip file stored in it multiple times (probably recursive until I delete the zip file).
As for the .cbplugin format please can you modify the page you did and remove the info as it is duplicated on the following page along with allot more info for a developer:
http://wiki.codeblocks.org/index.php/Managing_Plug-in_Resources
I would suggest on the page you modify the General section where the If you are developing plugins to the following as is has a few issues:
If you are developing plugins:
* Please read the "http://wiki.codeblocks.org/index.php/Managing_Plug-in_Resources" page for creating and producing a plugin.
* You will need to store the source code for the plugin for other developers to have access to it. You can do this on SourceForge or Github or your favorite source code repository web site.
* Setup your own webpage on a file sharing platform that can be used for documenting and distribution of the plugin. This will allow users to download the plugin to install on their Code::Blocks installation.
Once you have a working and production ready plugin for other developers to use then you can do the following:
* Read the "https://wiki.codeblocks.org/index.php/Announcement_for_plugins/patches" page for information on how to announce you have a plugin on the Code::Blocks forum.
* In your announcement in the "https://forums.next.codeblocks.org/index.php/board,14.0.html" forum please also ask for your plugin to be added to the Code::Blocks "https://wiki.codeblocks.org/index.php?title=Code::Blocks_Plugins" wiki page with the details you would like to see on the page.
One issue with this is that the referenced pages are not up to date either, so when do you stop..... Also it seems that some of the info is on multiple pages or it may be very similar info which is not right as later if one page gets updated and not the other then there may be issues.
Repackaged plugin is available from the following page:
https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/0.2.6%20-%2013JAN2022/ (https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/0.2.6%20-%2013JAN2022/)
I have updated the Wiki with your suggestions
Quote from: AndrewCot on January 13, 2022, 07:58:01 AM
@ollydbg In the plugin manager you specify the zip file instead of a .cbplugin and it works
I have rename the .zip file to .cbplugin, because I can't select a zip file in the plugin manager to install the new plugin(NO zip files will be shown in the file select dialog).
In the Windows-LLVM-ClangD-Install-Readme.txt
Quote
MSYS2 Compiler - MinGW64
-------------------------
a) Install MSYS 2 clang packages via the msys2.exe bash shell:
pacman -S mingw-w64-clang-x86_64-toolchain
Run this command, I got this:
# 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):
Do I need to only select the option
1?
Or do I need to use the
all?
EDIT:clangd is contained in mingw-w64-clang-x86_64-clang-tools-extra, so normally we should use option
3.
I also see the "LSP_DidOpen() error: [json.exception.type_error.316] invalid UTF-8 byte at index 1019: 0xB5" message box.
A quick search gives this related discussion:
[json.exception.type_error.316] invalid UTF-8 byte at index 1: 0xC3 Issue #1383 nlohmann/json (https://github.com/nlohmann/json/issues/1383)
Invalid UTF-8 byte at index 1: 0x65 Issue #1831 nlohmann/json (https://github.com/nlohmann/json/issues/1831)
I'm not sure how we pass the source file to clangd, maybe the file is not encoded in UTF8, but you pass the file to clangd as a UTF8 format file, and in this case, clangd return a string which is not encoded in UTF8. And finally we get the exception message box.
What is the encoding of your source file?
Quote from: BlueHazzard on January 13, 2022, 06:10:45 PM
What is the encoding of your source file?
The data sent to clangd comes directly from the editors' wxTextctrl.
The encoding in the status bar for my CB shows windows-1252.
This problem only occurs on the incoming textDocument/completion response.
The data going out never gets a json exception. Only the data coming in.
How can I determine what the encoding is for the outgoing data?
For the time being, I've coded a hack for the illegal utf8 problem.
It clears the illegal utf8 char and continues with the code completion.
The completion suggestions are correct so I'm ok with it.
I'll figure it out some other time.
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. :(
Quote from: ollydbg on January 15, 2022, 04:08:33 AM
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. :(
Can you give me some guidance as to how you created the problem. I can't make it happen here.
What source are you using that got a utf8 invalid char?
What symbol were you trying to code complete.
What indication are you getting that there was an invalid utf8 char. A wxMessageBox or an error shown in the cb debug log?
If a message was in the CB debug log, what did it say?
Did you use the repo source or the download file ?
In plugin management, what is the version you see for clangd_client?
I don't think the download files have been updated yet.
Thanks for testing.
The plugin download does not have the fix in it.
Hi, I try to debug this plugin, but I have always have this line hit:
// ----------------------------------------------------------------------------
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;
}
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:
D:\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:
$(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:
$(TARGET_DEVEL_DIR)\src\devel31_64
Which is the folder where codeblocks.exe locates.
5, I change the post build script as:
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
This means I make a clangd_client.zip, and put it in the destination devel31_64 folder.
Quote from: ollydbg on January 15, 2022, 02:15:44 PM
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:
D:\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:
$(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:
$(TARGET_DEVEL_DIR)\src\devel31_64
Which is the folder where codeblocks.exe locates.
5, I change the post build script as:
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
This means I make a clangd_client.zip, and put it in the destination devel31_64 folder.
The variable m_CodeCompletionEnabled should,in fact, be false.
Note that the line: m_CodeCompletionEnabled = ccmcfg->ReadBool(_T("/code_completion"), false);
is asking if the old code_completion is enabled. It not asking if "/clangd_client" is enabled.
"/code_completion" must be disabled for clangd_client to run.
I'll change the comments to make that clearer.
Edit: 2022/01/15 10:30
I might be wrong about this. I'll do more checking.
The .cbp you've created look good.
Just a little more information.
Run or debug the CB you created the plugin for.
In the menu for the running debugged/run CB
Go to MainMenu=>Plugins=>Manage Plugins and tell us what the clangd_client plugin version is:
(https://forums.next.codeblocks.org/index.php?action=dlattach;topic=24357.0;attach=11062;image)
@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.
Quote from: Pecan on January 15, 2022, 10:32:40 PM
@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.
Quote from: Pecan on January 15, 2022, 09:51:15 PM
@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.
I'm using the same CB personality cbDebug315 as yours. Because I'm running the debugger from the clangd_client_wx31_64.cbp.
Quote from: ollydbg on January 16, 2022, 02:10:21 AM
Quote from: Pecan on January 15, 2022, 10:32:40 PM
@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 ?
I think your debugged CB (the debuggee) has that box unchecked.
Would you give us a snapshot of your debugged CB Settings/Editor/Code completion box while the debugger is running?
Thanks for testing. It helps.
Quote from: Pecan on January 16, 2022, 02:34:34 AM
Quote from: ollydbg on January 16, 2022, 02:10:21 AM
Quote from: Pecan on January 15, 2022, 10:32:40 PM
@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 ?
debugee.
This is the whole patch I'm using:
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>
Note that the post build command has changed, I just removed the last " > nul", which causes some warning.
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.
Quote from: Pecan on January 16, 2022, 03:17:19 AM
@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.
Hi, Pecan, thanks for the help, I will try to debug this issue and see what happens in the code.
I see some code:
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;
}
My guess is that:
const char* pText = strText.mb_str(); Is this correct?
From my point of view, it should be:
QuoteFinal 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 as
const char *p = s.ToUTF8();
...
puts(p); // or call any other function taking const char *
This is from wx document here: https://docs.wxwidgets.org/trunk/overview_unicode.html
I make a clean git svn clone, and it looks like the clangd_client can be active now. I'm not sure why.
I see that the changes in my previous post did solve the error message issue. Here is the whole patch I use.
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()) );
Note the change in :
msg << "\'" << wxString::Format("%x", invChar ) << "\'";
is also try to suppress a message alert box(an ascii char to wxString convert, but the invChar value is bigger than 127)
@ollydbg
Thanks for working on that. I'll give those changes a test tomorrow.
I have another patch, it looks like this code should be enabled:
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**
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". :)
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.
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);
}
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:
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}}
Quote from: ollydbg on January 17, 2022, 12:32:16 PM
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:
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
I see there are some code snippet like:
m_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.
Quote from: ollydbg on January 17, 2022, 01:14:47 PM
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.
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);
}
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:
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}}
This is caused by clangd sending a message (usually a code completion response) with an illegal utf8 char. Clangd sets the message with a header specifying the wrong length which eats up the content-header for the following message.
I have to correct the situation by searching for the content-header.
I have now commented out that message box. The code works to correct the situation so we don't need that anymore.
Thanks for testing and finding these "gotchas" I've forgotten about.
Quote from: ollydbg on January 17, 2022, 02:56:17 PM
Quote from: ollydbg on January 17, 2022, 12:32:16 PM
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:
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
Thanks for that.
I've added code to remove preamble-*.tmp and preamble-*.pch files when the project closes.
I'll later add an option to keep the .pch in memory. (For me, I'd rather keep them on disk and remove them at project close time).
As an aside: Windows does not allow me to remove files that are open and being used. But Linux does. Do you know of a way to tell Linux NOT to allow me to delete open files?
Quote from: ollydbg on January 18, 2022, 12:35:08 PM
I see there are some code snippet like:
m_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.
Quote from: Pecan on January 18, 2022, 08:54:19 PM
Quote from: ollydbg on January 18, 2022, 12:35:08 PM
I see there are some code snippet like:
m_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.
Yes, there are only There are only 2 locks in the code. Sometimes, I got error message about lock failed, I'm not sure why.
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?
Quote from: ollydbg on January 20, 2022, 08:07:39 AM
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.
Quote from: Pecan on January 20, 2022, 11:49:52 PM
Quote from: ollydbg on January 20, 2022, 08:07:39 AM
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.
Hi, Pecan. Thanks for the explanation.
I'm surprised to find that you implemented the symbol tree. This is really a good job!
FYI:
I have make a simple wiki page:
CB Clangd Client - Code::Blocks (https://wiki.codeblocks.org/index.php/CB_Clangd_Client)
;)
Quote from: ollydbg on January 22, 2022, 08:32:18 AM
FYI:
I have make a simple wiki page:
CB Clangd Client - Code::Blocks (https://wiki.codeblocks.org/index.php/CB_Clangd_Client)
;)
Thanks, Someday I'll get a chance to add more info.
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.
I see an alert from this code snippet, and here is the fix:
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":{
When debugging, I see that the "invChar" is 161(dec), and it cause the alert from wx.
So, we have to first convert to "unsigned int".
See the document from: wxWidgets: wxUniChar Class Reference (https://docs.wxwidgets.org/3.0/classwx_uni_char.html#a8838f0ebdf714f804cbeaf70aabb4f77)
Quote
wxUniChar::wxUniChar ( unsigned char c )
Create a character from the 8-bit character value c using the current locale encoding.
Quote from: ollydbg on January 23, 2022, 12:47:55 PM
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.
I do, but others did not. Wasn't worth quibbling about to me.
Thanks for the wxUniChar fix.
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:
Error: Removed clangd response invalid utf8 char:position(3665), hex(85), U(2026), <cant post> ResponseID:textDocument/completion
Note that I get the codepoint U(2026) back.
With "wxUniChar uniChar(unsigned int(invChar));" I get:
Error: Removed clangd response invalid utf8 char:position(6899), hex(85), U(85), ,<cant post on sf>. ResponseID:textDocument/completion
Here I get only the hex value.
So I changed the wxString::Format to:
msg += wxString::Format("position(%d), hex(%02hhX), U(%x), \'%s\'", invloc, (unsigned int)invChar, (int)uniChar.GetValue(), invStr );
Note the "(int)uniChar.GetValue()"
I'm using wx3.1.5 on windows and wx3.0 on linux.
Works with no asserts.
Does it work for you
Note: it took me 45 minutes to post this. Don't try and post a msg with an invalid utf8 char. It's a PITA
Quote from: AndrewCot on January 23, 2022, 10:43:26 PM
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" />
For generated files, I prefer the lower case file name format. Since you have the commit right to the svn repo, can you fix them?
BTW:
The custom variables in build options can be improved from my point of view:
1, I see "TARGET_DEVEL_DIR_AC" and "TARGET_DEVEL_DIR_PECAN" and "TARGET_DEVEL_DIR" in custom variables. Can we just keep only one variable? I mean we can use a "global variable" in the Menu->Settings->Global variables. This way, we can set those variables by our own setting.
2, the name TARGET_DEVEL_DIR is not correct here. I think "DEVEL_DIR" mainly refer to a folder named "devel31_64" which store the built exe or dlls. So, a better name could be "CB_SOURCE_ROOT" which refer the the root of the svn/git source code root folder.
Quote from: Pecan on January 23, 2022, 11:46:27 PM
@ 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:
Error: Removed clangd response invalid utf8 char:position(3665), hex(85), U(2026), <cant post> ResponseID:textDocument/completion
Note that I get the codepoint U(2026) back.
With "wxUniChar uniChar(unsigned int(invChar));" I get:
Error: Removed clangd response invalid utf8 char:position(6899), hex(85), U(85), ,<cant post on sf>. ResponseID:textDocument/completion
Here I get only the hex value.
So I changed the wxString::Format to:
msg += wxString::Format("position(%d), hex(%02hhX), U(%x), \'%s\'", invloc, (unsigned int)invChar, (int)uniChar.GetValue(), invStr );
Note the "(int)uniChar.GetValue()"
I'm using wx3.1.5 on windows and wx3.0 on linux.
Works with no asserts.
Does it work for you
In my computer, it works differently than yours.
I did a simple test:
unsigned char invChar = 0x83;
wxUniChar uniChar(invChar);
wxString msg = wxString::Format("hex(%02hhX), U(%x)", (unsigned int)invChar, uniChar.GetValue());
wxLogMessage(msg);
With the above code, the program just pop up an alert (see screen shot in attachment)
While, with below code, it works OK without the alert.
unsigned char invChar = 0x83;
wxUniChar uniChar((unsigned int)invChar);
wxString msg = wxString::Format("hex(%02hhX), U(%x)", (unsigned int)invChar, uniChar.GetValue());
wxLogMessage(msg);
Please note that "Create a character from the 8-bit character value c using the current locale encoding.", which means in my locale encoding, a 0x83 is not a valid Unicode code point, I mean maybe we need two bytes or three bytes to convert it to a Unicode code point.
I'm not sure why in your test case, a 0x83 will becomes a larger value code point U(2026). Maybe, you have different locale encoding as mine. I'm on Windows 7 64bit Chinese language edition, so my local encoding maybe some Chinese language.
Quote
Note: it took me 45 minutes to post this. Don't try and post a msg with an invalid utf8 char. It's a PITA
I also meet this kind of forum error from time to time. So bad.
This is a code format fix:
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() )
It works fine for my first try. Its so cool.
My local environment:
wx 3.1.6
gcc 11.2
newest cb
Thanks your GREAT job!
The changes in commit r12689 may apply to this plugin.
Thanks. I created a ticket in the SF clangd_client project so that it gets tested and checked when time permits.
Quote from: Miguel Gimenez on February 02, 2022, 09:37:22 AM
The changes in commit r12689 may apply to this plugin.
Applied to clangd_client rev 39/40; Thanks Miguel and Andrew
Hi, Pecan, I see some code snippet:
ConfigManager *cfgApp = Manager::Get()->GetConfigManager(_T("app"));
bool i18n = cfgApp->ReadBool(_T("/locale/enable"), false);
I think the i18n is not a correct variable to check whether the later "(unsigned int)invChar" should be casted.
I think the i18n is used to identify whether a custom language translation is used for the GUI. For me, this value is false, because I use the default English version.
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.
Quote from: ollydbg on February 03, 2022, 04:03:39 PM
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.
Quote from: Pecan on February 03, 2022, 07:20:50 PM
Quote from: ollydbg on February 03, 2022, 04:03:39 PM
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.
Hi, thanks for the explanation.
I see in my setting: Setting->Editor->Clangd_Client->C.C++ parser(tab)->Concurrently parsing threads.
This value is 1. (I haven't change this value, so the default value is 1)
By reading the source code, I see that if the value is 1, it means we only let the indexer use 1 thread of the total CPUs. In my PC, I have a CPU with 4 threads.
So, the expected cpu usage should be 25%, am I correct?
Here is a test:I set the value: Setting->Editor->Clangd_Client->C.C++ parser(tab)->Concurrently parsing threads. to 2.
Now, I see that the cpu usage of clangd.exe is about 50%.
This is interesting, as 2 means 2/4 = 50%, which is correct.
But why the cpu usage is 75% if I set the value to 1?, I did test again, and see it is 25%, so sorry about that wrong report :(. I may looked wrongly at the the "System Idle process" cpu usage, because when the clangd.exe use 25% cpu, and the 75% cpu is from the Idle process.
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)
Quote from: ollydbg on February 04, 2022, 07:55:56 AM
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)
Thanks for that information. I've often thought it would be nice to persist the clangd .cache
and the symbols tree.
I'll put it on the ToDo list.
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)
// 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 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:
19:17:44: File 'D:\code\plugin\wxModularApp\build\.cache\Clangd-cache.lock' couldn't be removed (error 2: 系统找不到指定的文件。)
19:17:45: File 'D:\code\plugin\wxModularApp\build\.cache\Clangd-cache.lock' couldn't be removed (error 2: 系统找不到指定的文件。)
19:17:45: File 'D:\code\plugin\wxModularApp\build\.cache\Clangd-cache.lock' couldn't be removed (error 2: 系统找不到指定的文件。)
19:17:45: File 'D:\code\plugin\wxModularApp\build\.cache\Clangd-cache.lock' couldn't be removed (error 2: 系统找不到指定的文件。)
The Chinese words means "System cannot find the file specified.".
So, I think that this plugin use the same .lock file name for all the cbp projects?
BUG2:
1, I have 5 cbp files in the same folder, and I also have a workspace file which contains the 5 cbp files.
2, I open the workskpace, and switch the active project between those 5 cbps.
3, Now, I use the git tool to update those 5 cbp files, and C::B asked that whether I need to reload the cbp files, I press "all".
Now, I see that my CPU usage is from the 25% CPU (which is the 1 thread in my clang_client setting) to 100%, and I see 4 clangd.exe running in the task manager window.
Each process of clangd eat about 25% of the cpu.
I guess that when 5 cbp files get reloaded in the same time, it will trigger several clangd.exe to run.
My testing project is:
asmwarrior/wxModularApp: Cross-Platform Modular Application (Main app + plugins) example for C++/wxWidgets (https://github.com/asmwarrior/wxModularApp)
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.
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:
MSYS2 Compiler - MinGW64
-------------------------
There are two main options to install the clangd.exe as follows:
1) The first option in order to minimise disk space is to install the Clang extra tools using one of the following packages:
+------------------------------------------+------------------------+
| Package | Clangd executable |
+------------------------------------------+------------------------+
| mingw-w64-clang-x86_64-clang-tools-extra | clang64/bin/clangd.exe |
| mingw-w64-x86_64-clang-tools-extra | mingw64/bin/clangd.exe |
+------------------------------------------+------------------------+
To intall the package do the following:
a) Open the msys2.exe bash shell
b) Run the following command:
pacman -S <Package name in the table above>
OR
2) The second option is to intall the full Clang tool chain as follows:
a) Open the msys2.exe bash shell
b) Run the following command:
pacman -S mingw-w64-clang-x86_64-toolchain
If you are using the gcc from msys2, I mean the compilers in the folder "msys64\mingw64\bin", you should use "mingw-w64-x86_64-clang-tools-extra", which means the clangd.exe is under the folder "msys64\mingw64\bin" (the same folder in your gcc.exe).
If you are using the clang tool chain, I mean you use the compiler from the folder "msys64\clang64\bin", you should use "mingw-w64-clang-x86_64-clang-tools-extra".
I found that I just make a big mistake in one of my PC, that is I use the gcc toolchain from "msys64\mingw64\bin", but I use the clangd.exe from "msys64\clang64\bin", the result is I got a lot of LSP diagnostics messages about the errors. ;) Luckily I found the reason, and fix this issue. Hope this will help other guys. :)
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.
Quote from: AndrewCot on February 11, 2022, 04:25:30 AM
Can you raise a ticket for this so I do not forget about it as it may not be as simple as changing the docs as the code may need some changes to ensure that end users with GCC and CLANG do not have issues like you found.
Done.
CB Clangd Client / Tickets / #37 use the compiler and clangd from the same folder(for msys2 the same package repositories) (https://sourceforge.net/p/cb-clangd-client/tickets/37/)
Fixed rev 44
Quote from: ollydbg on February 08, 2022, 12:31:07 PM
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:
19:17:44: File 'D:\code\plugin\wxModularApp\build\.cache\Clangd-cache.lock' couldn't be removed (error 2: 系统找不到指定的文件。)
19:17:45: File 'D:\code\plugin\wxModularApp\build\.cache\Clangd-cache.lock' couldn't be removed (error 2: 系统找不到指定的文件。)
19:17:45: File 'D:\code\plugin\wxModularApp\build\.cache\Clangd-cache.lock' couldn't be removed (error 2: 系统找不到指定的文件。)
19:17:45: File 'D:\code\plugin\wxModularApp\build\.cache\Clangd-cache.lock' couldn't be removed (error 2: 系统找不到指定的文件。)
The Chinese words means "System cannot find the file specified.".
So, I think that this plugin use the same .lock file name for all the cbp projects?
BUG2:
1, I have 5 cbp files in the same folder, and I also have a workspace file which contains the 5 cbp files.
2, I open the workskpace, and switch the active project between those 5 cbps.
3, Now, I use the git tool to update those 5 cbp files, and C::B asked that whether I need to reload the cbp files, I press "all".
Now, I see that my CPU usage is from the 25% CPU (which is the 1 thread in my clang_client setting) to 100%, and I see 4 clangd.exe running in the task manager window.
Each process of clangd eat about 25% of the cpu.
I guess that when 5 cbp files get reloaded in the same time, it will trigger several clangd.exe to run.
My testing project is:
asmwarrior/wxModularApp: Cross-Platform Modular Application (Main app + plugins) example for C++/wxWidgets (https://github.com/asmwarrior/wxModularApp)
Added your comment to the Install instructions
Rev 44. Thanks
Quote from: ollydbg on February 11, 2022, 03:26:20 AM
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:
MSYS2 Compiler - MinGW64
-------------------------
There are two main options to install the clangd.exe as follows:
1) The first option in order to minimise disk space is to install the Clang extra tools using one of the following packages:
+------------------------------------------+------------------------+
| Package | Clangd executable |
+------------------------------------------+------------------------+
| mingw-w64-clang-x86_64-clang-tools-extra | clang64/bin/clangd.exe |
| mingw-w64-x86_64-clang-tools-extra | mingw64/bin/clangd.exe |
+------------------------------------------+------------------------+
To intall the package do the following:
a) Open the msys2.exe bash shell
b) Run the following command:
pacman -S <Package name in the table above>
OR
2) The second option is to intall the full Clang tool chain as follows:
a) Open the msys2.exe bash shell
b) Run the following command:
pacman -S mingw-w64-clang-x86_64-toolchain
If you are using the gcc from msys2, I mean the compilers in the folder "msys64\mingw64\bin", you should use "mingw-w64-x86_64-clang-tools-extra", which means the clangd.exe is under the folder "msys64\mingw64\bin" (the same folder in your gcc.exe).
If you are using the clang tool chain, I mean you use the compiler from the folder "msys64\clang64\bin", you should use "mingw-w64-clang-x86_64-clang-tools-extra".
I found that I just make a big mistake in one of my PC, that is I use the gcc toolchain from "msys64\mingw64\bin", but I use the clangd.exe from "msys64\clang64\bin", the result is I got a lot of LSP diagnostics messages about the errors. ;) Luckily I found the reason, and fix this issue. Hope this will help other guys. :)
Fixed rev 44.
Also added settings option to perform in the current manner.
Quote from: ollydbg on February 09, 2022, 11:05:58 AM
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.
Fixed in a rev previous to 44. Forgot to mention it.
Thanks for testing.
Quote from: ollydbg on February 07, 2022, 02:30:39 PM
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)
// 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?
Hi, Pecan, thanks for your fix!
r46 version : typos : two new strings start by "Warings", should be "Warnings".
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)
Quote from: BlueHazzard on March 04, 2022, 12:49:42 AM
I get a lot of this message boxes (see image)
and they block the workflow quite hard. Would it be possible to log this error messages only to console, and not show a message box?
As far as i can tell they do not interfere with the plugin, at least it seems to work.
(i use not the last version of the plugin. If this is fixed in the last version please ignore this, i will update the source soon)
Those boxes were removed quite awhile back and written to the debug log instead.
You might want to download the nightly .dll and .zip, or update your clangd_client source.
Thanks for testing.
Is it possible to enable macro expansion for the llvm master path?
I mean this code:
ConfigManager* cfg = Manager::Get()->GetConfigManager(_T("clangd_client"));
wxString cfgClangdMasterPath = cfg->Read("/LLVM_MasterPath", wxString());
For example, we can enter such string in the clangd_client setting dialog.
$(TARGET_COMPILER_DIR)bin\clangd.exe
BTW: I use the string: $(TARGET_COMPILER_DIR)bin\gdb.exe
under the GDB plugin setting.
I try to use clangd plugin. I use Msys2 and the compiler installed in mingw64/bin, so following your recommandations I have installed with pacman mingw-w64-x86_64-clang-tools-extra.
clangd is installed in mingw64/bin normally. After the first installation my clang64 folder contains only empty folders (\bin, ...). I don't use clang compiler, so that's normal. Like that, clangd plugin works as it should.
Nevertheless, after some time and a few pacman updates, I see several warnings during the update process, and clang64 folders are progressively filled with different files. May be the pacman update process is not well adapted to the installation of clangd inside mingw64 folders ! Dependencies may be ? And all those new files are probably not necessary for clangd client plugin.
My question is : what is striclly necessary for clangd client usage : clangd.exe + a few dlls (used by clangd.exe or may be a static version of clangd.exe), sure, but is there anything else, other dll, other executables ? could we remove the update process to avoid unnecessary filling of clang64 folder ?
QuoteNevertheless, after some time and a few pacman updates, I see several warnings during the update process, and clang64 folders are progressively filled with different files. May be the pacman update process is not well adapted to the installation of clangd inside mingw64 folders ! Dependencies may be ? And all those new files are probably not necessary for clangd client plugin.
I have run the pacman updates today, and I didn't see such issue. I have clang64 folder, and I see there are some sub folders in this folder, but all are empty.
QuoteMy question is : what is striclly necessary for clangd client usage : clangd.exe + a few dlls (used by clangd.exe or may be a static version of clangd.exe), sure, but is there anything else, other dll, other executables ? could we remove the update process to avoid unnecessary filling of clang64 folder ?
I guess your msys2 has some issue. You can try to remove the files/packages in clang64 folder, I have did that before, use such command:
pacman -R $(pacman -Qsq 'mingw-w64-clang-x86_64*')
I have already tried to uninstall all my msys2, using the pacman -R option and even delete everything manually (C:\msys64), reinstalling msys2 (in C:\msys64), reinstalling C:\msys64\mingw64 and only clang64 extra tools in mingw64. Everything happens correctly and clangd plugin works, but after a while and several upddates with pacman during a few weeks, my C:\msys64\clang64 folder is progressively filled with different things as python, sqlite, p11-kit, ... etc. clangd.exe is still in C:\msys64\mingw64\bin.
So, what could be wrong, I don't know.
PS:
I have tried your command line. Though I was sure everything was suppressed from a previous standard clang try, many packages have been found. Obviously, there was things in the cache that was still there, but not installed as far as I understand. May be that was my problem. Wait and see in 2 or 3 weeks !
@Ollydbg
Quote from: ollydbg on March 20, 2022, 04:02:06 AM
Is it possible to enable macro expansion for the llvm master path?
$(TARGET_COMPILER_DIR)bin\clangd.exe
Yes, I'll do that. Good suggestion.
I have an issue to use the "find declaration" tool.
Find the declaration of a symbol in a header file, but the header file is not belong to the cbp project.
I have a project, say, it has a file named a.cpp. In this file, I have some definition like
TypeA a;And the TypeA is defined in a header file (e.g. TypeA.h), which is not belong to the cbp project, say, it could be in a include search path.
Now, when I use the "find declaration of TypeA", I see LSP can correctly jump to the TypeA.h.
Now, say the TypeA is actually a typedef, such as:
typedef TypeB TypeA;
Now, when I right click on the TypeB symbol, and "find declaration of TypeB", I see the clangd_client plugin will jump a messagebox, it said:
Quote[Window Title]
LSP OnGotoDeclaration
[Content]
The editor's file does not have an associated project.
Perhaps add the file to a project ?
[OK]
This looks wrong, I mean if the a.cpp get parsed by clangd, it should understand where TypeB is declared. So, is this a bug? I think adding the TypeA.h to my cbp project is not the correct way to solve this issue.
Any ideas?
Thanks.
and what does it do with :
using TypeA = TypeB;
Quote from: killerbot on March 23, 2022, 05:29:58 PM
and what does it do with :
using TypeA = TypeB;
The same issue as the typedef.
Here is a simple test:
The cbp only contains main.cpp
#include "TypeA.h"
int main()
{
TypeA a;
return 0;
}And here are the TypeA.h
#include "TypeB.h"
// typedef TypeB TypeA;
using TypeA = TypeB;
Here is TypeB.h
class TypeB
{
public:
int abc;
};For testing, you can put the TypeA.h and TypeB.h in the same folder as main.cpp.
No, I can see that find declaration only goes from a file in cbp file to external file(a file not belong to cbp), such as main.cpp -> TypeA.h.
But find declaration will NOT go from an external file to an external file, so it failed from TypeA.h ->TypeB.h.
This is really an annoying issue. (BTW: our old code completion plugin works OK on this issue :) )
// ----------------------------------------------------------------------------
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? :) Because I can only find some information about clangd in this page: What is clangd? (https://clangd.llvm.org/), I'm not sure where is the official document of clangd, maybe I need to read the document about LSP?
EDIT:
Maybe, the LSP document is here:
language-server-protocol/protocol-2-x.md at main microsoft/language-server-protocol (https://github.com/Microsoft/language-server-protocol/blob/main/versions/protocol-2-x.md)
Quote from: ollydbg on March 25, 2022, 04:04:29 AM
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.
Quote from: Pecan on March 25, 2022, 05:44:33 AM
Quote from: ollydbg on March 25, 2022, 04:04:29 AM
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.
Hi, Pecan, thanks for the reply.
Maybe, we can have a mechanism that if a non-project file is opened in the editor, we can dynamically add(send) it to the clangd's database, and once the editor is closed, its content(the file) can be dynamically removed from the clangd's database.
This is only a guess.
Because, for my previous example, if I put the "TypeA.h", "TypeB.h" in the cbp file, then I see the find declaration works correctly in either header files. :)
EDIT:This issue maybe is related to this github issue:
Support non-self-contained files Issue #45 clangd/clangd (https://github.com/clangd/clangd/issues/45)
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.
Quote from: Pecan on April 25, 2022, 08:59:46 PM
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.
Thanks, great work!
But I got build errors, see below build logs:
-------------- 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))
The code snippet is around codecompletion.cpp line 2979, see below:
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);
}
With this rev i get the following compiler errors:
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'|
[edit:] ollydbg was faster....
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 !!
Quote from: Pecan on April 26, 2022, 04:29:52 AM
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 !!
Hi, Pecan, thanks for the fix.
In rev 52, why do you add a clangd_client.zip file to the repo?
BTW: I don't use TortoiseSVN, instead, I use TortoiseGit, and the git-svn bridge works OK in TortoiseGit.
EDIT:CC_ProxyProject.cbp, what does this cbp file used for?
Quote from: ollydbgIn 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?
That zip file got there out of frustration with Tortoise svn.
I gave up and just updated with everything from my local trunk.
I'll delete it for the next update. Thanks for the heads-up.
Re: CC_ProxyProject.cbp.
It's a hidden cbProject used to contain files that are not associated with a project. To send a file to clangd, we need info containing it's location and compile commands.
It's used to avoid making any changes to user workspaces and projects.
A file (not belonging to a project but needing to be parsed) is added to this "~ProxyProject~" and then sent through the code that prepares the info that clangd needs.
For Example, To solve the problem described by https://forums.next.codeblocks.org/index.php/topic,24357.msg169687.html#msg169687
"TypeA.h" and "TypeB.h" must be scanned by clangd in order to ask for its symbols to use in a GoToDecl/Impl request (or any other request to clangd).
Since the files don't belong to a project, they're just added to a hidden project and sent off to clangd via the usual process.
CB requires a filename in order to create a project.
We can't even issue a "pointer = new cbProject()" without a filename.
So the clangd_client code puts an empty project in the users' appdata/codeblocks folder and loads it, clones it, closes it, then hides the clone.
Loading and closing it via ProjectManager is necessary to keep from screwing up the order of plugin notifications.
This one-and-only hidden ~ProxyProject~ is created at OnAppStartupDone() and removed at CB clangd_client shutdown. It's the equivalent of the old CodeCompletion hidden temp parser.
Thanks for testing !
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.
1) Using a medium sized projects (75 .cpp files for 20000 lines of code) the time needed for a complete parsing is 5 minutes (4 seconds for each file). I was expecting that at the first time the full parsing is needed. Then I closed the project and reloaded it (without closing CB). Then a full re-parsing is done by CB for other 5 minutes. Because I didn't modify any source file I was expecting that no re-parsing is required. Waiting 5 minutes, before having a "ready" code completion, each time I open the project seems too much considering that no modifications was applied. Is there a way to avoid a full re-parsing each time I open a project? May be no but I'm wondering if some optimization is possible just re-paring modified files.
2) I typed some code in a file to have a test of the parser making some bad indentation and syntax error like typing "elset" instead of typing "else". During typing the LSP messages window is reporting various issues and a red rectangle appeared at the involved line. Then I corrected the errors but nothing happened. The red rectangle is still there! Saving the file the red rectangle disappeared. It seems that saving the file is required to refresh the parser errors/warnings despite I selected the "Update parser when typing". Is this behavior expected? Have I to save the file to refresh the parser status anyway?
3) During typing it's easy to get messages related to indentation like
LSP diagnostics: AteReaders.cpp|:|----Time: 23:19:23.784---- (1 diagnostic)|
C:\Development\Projects\AteSfp28BiDi\AteReaders.cpp|56|warning:Different indentation for 'if' and corresponding 'else'|
Because it's not a major issue, considering also the topic 2), a good idea could be to have an option to ignore indentation issues. Moreover I'm wondering which indentation rules are used. Different teams may have different indentation rules for their projects. So it's possible to ignore the indentation warnings as an option?
Thank you in advance for your attention.
Max
Quote from: MaxGaspa on June 30, 2022, 11:24:03 PM
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.
@Max
Firstly, thanks for testing.
Regarding 1)You do not have to wait for the background parsing to finish.
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 3-7 seconds to use code completion or other clangd features from within the active editor.
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.
Regarding 2)Currently, changes on a single line need to be saved manually. Changes on multiple lines usually are recognized and clangd reparses the file. This is how the older codecompletion worked but I'll see if I can do a little better in a furture fix.
Regarding 3)CodeBlocks clangd_client has no control over what clangd reports as a warning. However you can hide the warning as follows:
With the warning in the LSP messages log, right click on the "LSP messages" tab and click on "Show/set ignore messages". In the resulting dialog, check the box for the messages you want to ignore.
Regarding Indentation:I have no idea what indentation rules clang/clangd is applying to source files.
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.
I updated during the week and have been updating my scripts for building both wx 3.1.7 and 3.2. and have not finished all of the combinations. Once I do I will see if I get the same results for r67, unless it is resolved by then. I hope it does not take more than another 2 days to finish.
Quote from: ollydbg on July 09, 2022, 06:55:37 AM
I'm building this plugin with the latest wx 3.2.0 release.
The source code I use is the latest rev: [r67] (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?
Quote from: Pecan on July 10, 2022, 06:05:03 PM
That message box is still in rev 66 also. So some logic changed that is causing clangd to send back an empty response in rev 67.
Can you tell me how to re-create the situation with rev 67?
I'm using C::B for my own big project.
Let me create a minimal project for testing(reproduce this bug)
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:
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;
However, I see the string "..\usr\bin" is wrong here.
Because in the C::B Menu->Settings->Compiler->Tool Chain executable->Addtional Paths, I have one string
$(TARGET_COMPILER_DIR)../usr/bin
So, it looks like the TARGET_COMPILER_DIR is not replaced by the "F:\code\msys2-64\mingw64".[/code]
Quote from: ollydbg on July 11, 2022, 07:44:47 AM
Quote from: Pecan on July 10, 2022, 06:05:03 PM
That message box is still in rev 66 also. So some logic changed that is causing clangd to send back an empty response in rev 67.
Can you tell me how to re-create the situation with rev 67?
I'm using C::B for my own big project.
Let me create a minimal project for testing(reproduce this bug)
Here is my research on the "find declaration failure".
For some unknown reasons, the find declaration gives empty result, see the log below:
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":[]}
While for another place, it works OK, see the log below:
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"}]}
So, it looks like the problem is in clangd side.
I will do more research on this issue, and try to make a minimal sample code.
Strange that clangd does not show the errors when parsing:
LSP diagnostics: JsonRead.cpp|:|----Time: 11:30:08.905---- (0 diagnostics)|
I stripped down to a minimal code snippet: (you should save the code to UTF8 format)
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;
}
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:
// 上面的函数
Then, everything works expected.
Can you guys reproduce this bug?
Thanks.
BTW: I have some local patches to enable the the utf8 handling, but I'm not sure they are related.
-------------------- 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
and
-------------------- 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**
Quote from: ollydbg on July 12, 2022, 04:30:41 AM
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:
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;
However, I see the string "..\usr\bin" is wrong here.
Because in the C::B Menu->Settings->Compiler->Tool Chain executable->Addtional Paths, I have one string
$(TARGET_COMPILER_DIR)../usr/bin
So, it looks like the TARGET_COMPILER_DIR is not replaced by the "F:\code\msys2-64\mingw64".[/code]
I don't understand the point here.
That line in the log is just info produced by client.cpp line 372 and line 394. It's the system path as seen by wxGetEnv() and is just for information.
wxString envPath;
wxGetEnv("PATH", &envPath);
logLine = "SystemPath: " + envPath;
writeClientLog(logLine);
The code to find the path to clangd.exe is in Locate_ClangdDir() invoked at client.cpp line 195.
Search for "// Locate folder for Clangd" (without quotes).
Quote from: ollydbg on July 12, 2022, 07:23:18 AM
I stripped down to a minimal code snippet: (you should save the code to UTF8 format)
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;
}
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:
// 上面的函数
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.
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"}]}
Attached: a .zip of a .wmv recording the sucessful behavior.
Quote from: Pecan on July 14, 2022, 07:42:43 PM
Quote from: ollydbg on July 12, 2022, 07:23:18 AM
I stripped down to a minimal code snippet: (you should save the code to UTF8 format)
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;
}
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:
// 上面的函数
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.
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"}]}
Attached: a .zip of a .wmv recording the sucessful behavior.
Hi, Pecan, thanks for the test and the screen cast video. I will check what's the problem here.
BTW: do you use the wx 3.2 library? Or the wx 3.1.7 for building the codeblocks and the clangd_client.
@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.
Quote from: Pecan on July 15, 2022, 06:26:47 AM
@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.
Thanks for the reply and help.
I just added a "return 0;" statement in the main function, but the same issue.
I have rebuild the whole C::B and clangd_client plugin with the wx 3.2.0 today. But still the same issue.
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.
Quote from: ollydbg on July 15, 2022, 08:57:56 AM
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.
The issue persist with wx 3.1.7. So, it looks like this is not a wx related issue.
Can someone share a C::B + clangd_client plugin, so that I can tested in my PC? Thanks.
I have upload a screen cast mp4 file in zip file about this issue.
See here:
go declaration got error Issue 1 asmwarrior/clangd_client_bug_2022 (https://github.com/asmwarrior/clangd_client_bug_2022/issues/1)
Because this forum does not allow a file larger than 512K, I upload to github issue, clangd_go_decl_bug.zip (https://github.com/asmwarrior/clangd_client_bug_2022/files/9120484/clangd_go_decl_bug.zip)
Hi, Pecan, I did some test, I tred to use different clangd from winlibs, I tried to used to use the online visual studio code.
It looks like clangd does not have this issue. so I guess the issue is inside the clangd_plugin code. clangd_plugin rev66 about one months ago works OK.
I compared rev67 and rev66, especially the log file. By comparing the logs from clangd_plugin rev66 and rev67, I noticed some difference.
It looks like the textDocument/didOpen method is different. In rev67, it just send an empty string.
Here is the log of rev66, it looks good. (Note I cut down the source file path, because it was a bit long)
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}}}
In rev67, the log looks wrong, because an empty string is passed.
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}}}
You can see, the "text":"". So, it just send the empty string to the clangd?
OK, it looks like the change in rev67 is here:
@@ -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.
Quote from: ollydbg on July 16, 2022, 02:53:01 PM
OK, it looks like the change in rev67 is here:
@@ -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! :)
There are some other issues in rev67, which I never see in rev66.
When editing the comments, I got this message box:
[Window Title]
codeblocks.exe
[Content]
LSP: trying to get AST for non-added document
[OK]
I really don't know why this will happen.
Quote from: ollydbg on July 16, 2022, 04:41:59 PM
There are some other issues in rev67, which I never see in rev66.
When editing the comments, I got this message box:
[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.
Quote from: ollydbg on July 16, 2022, 03:13:32 PM
Quote from: ollydbg on July 16, 2022, 02:53:01 PM
OK, it looks like the change in rev67 is here:
@@ -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! :)
Thanks, I'll revert that change for the next commit.
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?
Quote from: Pecan on July 16, 2022, 06:16:54 PM
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?
Yes, I use UTF8 in the C::B editors. My source code is also in UTF8 format.
My question: The function wxString::utf8_string() returned a std::string type, but why you still use a wxString to hold the returned value? Maybe there is a conversion from std::string to wxString?
My OS: Windows7 64bit, but my OS' local language setting is Simplified Chinese. My guess is that some conversion is wrong here, maybe, a std::string to wxString is using some local language setting, and its not necessary.
Quote from: Pecan on July 16, 2022, 06:08:55 PM
Quote from: ollydbg on July 16, 2022, 04:41:59 PM
There are some other issues in rev67, which I never see in rev66.
When editing the comments, I got this message box:
[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.
OK, thanks for the explanation.
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.
[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]
I also got some message like the above in the rev67.
I checked the code change and it looks like:
@@ -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**
This may cause the issue.
EDIT: code in rev67.
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;
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();
Quote from: ollydbg on July 17, 2022, 09:40:34 AM
...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();
I will revert DidChange() and DidOpen() to rev66 since that code worked ok.
Then (after the revert commit) I'll make an experimental branch with your suggestions and have you test the changes.
Thanks for the suggestions and thanks for testing.
Quote from: ollydbg on July 17, 2022, 01:35:19 AM
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.
Yes, I know.
There needs to be some wait set between the time a closed file is opened and sent to clangd and when the code for GoTo Decl/Impl is executed. This probably is also true of FindReferences etc.
I'll enter this comment into the clangd_client repo ticket system.
(Ticket #54 in Clangd_Client repo)
Pecan, You can blow away my old experimental branch so that there is only one experimental branch.
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.
-------------------- 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**
Quote from: ollydbg on July 22, 2022, 07:12:37 AM
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.
-------------------- 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**
Applied locally. Will test it for awhile.
If ok, it'll be in rev 70.
Thanks
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:
Quote
wxLogMessage("aaa", aaa);
Then I will get this:
Quote
wxLogMessage("bbb", aaa);
maybe, clangd does not give us the column information of a variable? It just tell use the line information?
Quote from: ollydbg on July 24, 2022, 06:15:38 AM
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:
Quote
wxLogMessage("aaa", aaa);
Then I will get this:
Quote
wxLogMessage("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) ?
Quote from: Pecan on July 24, 2022, 06:58:20 AM
Quote from: ollydbg on July 24, 2022, 06:15:38 AM
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:
Quote
wxLogMessage("aaa", aaa);
Then I will get this:
Quote
wxLogMessage("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.
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:
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
@BlueHazzard, maybe you can check the log files in your system Temp folder to see what content were sent from the clangd.
Quote from: BlueHazzard on July 29, 2022, 10:04:45 PM
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:
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
This looks like the crashes during CB shutdown or when closing a file while clangd sent a response to a previous request.
Likely fixed in rev 70.
Quote from: ollydbg on July 24, 2022, 07:23:36 AM
Quote from: Pecan on July 24, 2022, 06:58:20 AM
Quote from: ollydbg on July 24, 2022, 06:15:38 AM
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:
Quote
wxLogMessage("aaa", aaa);
Then I will get this:
Quote
wxLogMessage("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.
Fixed rev 70
Quote from: ollydbg on July 30, 2022, 05:02:08 AM
@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:
client log:
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"}}}
server:
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"}}}
Quote from: ollydbg on July 30, 2022, 05:02:08 AM
@BlueHazzard, maybe you can check the log files in your system Temp folder to see what content were sent from the clangd.
To find a particular clangd_client log, look at the file "
CBclangd_LogsIndex.txt" in your temp folder.
Each line contains the processid, the date and time of the log, location of the clangd executable, and the CB project .cbp filename.
The logs are named:
\temp\CBclangd_client-<processID>.log
\temp\CBclangd_server-<processID>.log
The CBclangd_client-<processID>.log is the most interesting for debugging CB.
The CBclangd_client-<processID>.log is useful for probing/debugging clangd and is usually required to submit bug reports to the clangd team.
One log (not so interesting) exists for the CC_ProxyProject.cbp. It handles parsing non-project files.
Two logs for each opened project; The client log and the server log.
The first log line header contains the project it belong to. And the .cbp that created it. the time is on the left.
Edit: 2022/07/31
The log representing a project contains all clangd requests and responses for any file or any target.
In error, I said that there was a log for each target. Not so.
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
Quote from: BlueHazzard on July 31, 2022, 01:04:14 AM
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
I'm having a problem getting the crash.
Would you please copy your devel31_64 version of clangd_client.dll with the debug symbols over the top of your output31_64 version and post the crash .RPT file.
I was not able to re-create the crash, but I got a crash if I close C::B down while compiling which did not occur with the latest nightly. I close by clicking on the [X] on the top right of the C::B window. This crash does not include any ClangD-cleint functions, but does have event functions in the stack so there is a very small slim possibility it could be related and this is why I am posting it here just in case I am wrong.
-------------------
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
Hi, Pecan, if possible, can you have several more small svn commits instead of a big svn commit.
I mean I see your commit history(such as rev70), it mainly have several code changes from many places, and the expected way is for each logic code change, you should have a commit. This make the code a bit clean and easy to track.
Thanks.
BTW: The best way is using git, not svn. :)
Hi Pecan,
I' using the ClangdClientForCBNightly_20220813_rev12864_win64.zip with the latest CB nightly and I'm observing a minor issue and a crash. They are present on both Win7 Pro and Windows 10 Enterprise
The minor issue is related to the option "Update parser when typing )on save otherwise". I de-select this option because I'd like to update just when I'm saving the file. In reality the updating happens both when typing and (instead of otherwise) when saving. May be this is the implemented feature but in some cases the parser updating when typing is a little bit annoying, I think that updating just on saving can be very useful especially when you are typing a new code and several errors appears when I'm correcting them
The crash happens when the window, shown in the attached picture , is present in the editor. CB just freeze and the a crash happen. I'm also attaching the .RPT file related to this crash.
Hope this helps
Max
MaxGaspa, The type of crash in the rpt file has been seen before and Miguel has made some changes a month or two ago that reduced the occurrence of it, but it looks like it is still occurring. It is my understanding from what I have seen that the problem is not to do with the Clangd_Client plugin, but you just had the dialog up when it crashed.
Just before it crashed were you editing or had some other app (not C::B) in focus?
It looks like it could be the same or similar issue to the crashes as per the following ticket:
https://sourceforge.net/p/codeblocks/tickets/1168 (https://sourceforge.net/p/codeblocks/tickets/1168)
Quote from: AndrewCot on September 08, 2022, 12:21:10 AM
Just before it crashed were you editing or had some other app (not C::B) in focus?
I was editing the related file source file in CB ....
Max
The crash(both reported by MaxGaspa and https://sourceforge.net/p/codeblocks/tickets/1168/) looks like inside the CCManager code:
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
Mainly in the CCManager::OnPopupScroll function.
I'm beginning to think this actually is a clangd_client problem.
Clangd_client is using a feature of ccmanager that was never used before. Namely a call to ccmanager::NotifyDocumentation().
CodeCompletion never used it. No other code has ever used it. So this is a path through ccmanager that has previously never been thoroughly test.
I'm working on it.
Edit: 2022/09/13
As it turns out, the problem existed before clangd_client was created.
But clangd_client gets the problem also.
The html documentation popup gets stuck opened (usually by slow double-clicking on a completion selection) and cannot be closed. Using the mouse to focus outside CB then attempting to focus back into CB reveils the stall.
The debugger just shows (for me) "corrupted stack".
But I suspect the stall occurs before focusing outside CB.
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*
Quote from: gd_on on September 12, 2022, 04:26:59 PM
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*
I'm building C::B rev12886, and clangd_client rev76, I don't have build issue against wx 3.2.1.
Maybe the recent change from rev12887 to rev12890 causes the build issue.
Starting with r12887, if you are compiling with wxWidgets >= 3.1.6 the last parameter of CodeBlocksLogEvent must be a pointer to wxBitmapBundle.
The change is straightforward, I will publish a patch in this thread tomorrow (I have detected an error in the original notebook HiDPI code that must be fixed beforehand).
Bug fixed in r12891.
To fix the plugin replace (in client.cpp:3664) this
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));
with this
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
Hi, Miguel Gimenez, Thanks for the fix.
@ 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
Quote from: Pecan on September 13, 2022, 09:30:43 PM
@ 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
RFC: patch for ticket 1168.
This is a Request For Comment for the attached patch.
I have posted a patch on the second page of ticket #1168:
Direct link to Patch (https://sourceforge.net/p/codeblocks/tickets/_discuss/thread/92a1b2249a/e111/attachment/ccManagerMouseTrap220916-1.patch)
The attached patch (ccManagerMouseTrap220915-1.patch) resolves the following described conditions for both CodeCompletion and Clangd_client. The patch has been tested on both MSW and Linux.
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.
What is actually happening? (tldr version)
CB is getting stuck in function OnPopScroll statement:
else if (m_pAutocompPopup && m_pAutocompPopup->GetScreenRect().Contains(pos))in the GetScreenRect() function because the AutocompPopup window has been hidden and the HtmlDocumentationPopup may or may not be hidden, but a wxEVT_MOUSEWHEEL connection is owned by the html popup.
It seems that wxWidgets does not like this condition.
The debugger cannot even step out of this condition.
The problem usually arises from a slower double-mouse-click on an AutocompPopup item such that the double click gets interpreted as two single-clicks.
The AutocompPopup will get closed leaving the HtmlDocumentationPopup out to dry.
Now the conditions on which ccManager depended to remove the event connection will never be met.
We than have a happy deadly embrace.
Other sequences of action also cause the deadly embrace including (occasionally) un-focusing and re-focusing CB while both popups are showing.
I didn't trace through all the conditions causing the deadly embrace since the fix to avoid connecting wxEVT_MOUSEWHEEL to HtmlPopup when AutocompPopup was hidden fixed most of the other conditions also. (ie. the first fix eliminated the possibility of the others).
I did, however, trace through all listed conditions once the fix was applied locally.
I would like to apply the patch before the next nightly.
Comments please....
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!
About the ccManagerMouseTrap220915-1.patch file.
I'm not sure, but this variable
std::map<cbEditor*,bool> m_EdAutoCompMouseTraps;
The bool value is always "true"? Since I see the only code here is:
m_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.
Quote from: ollydbg on September 16, 2022, 07:50:24 AM
About the ccManagerMouseTrap220915-1.patch file.
I'm not sure, but this variable
std::map<cbEditor*,bool> m_EdAutoCompMouseTraps;
The bool value is always "true"? Since I see the only code here is:
m_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.
The declaration and all references to m_EdAutoCompMouseTraps are already guarded by "#ifdef __WXMSW__"
#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__
The statement:
m_EdAutoCompMouseTraps[ed] = true; is only used to enter the cbEditor* into the map assuring only one entry for this editor exists. Is there a better method for inserting a entry into a map?
It is removed by statement:
m_EdAutoCompMouseTraps.erase(m_pLastEditor);I will make a specific comment explaining that.
Thanks for reviewing.
I'm tweaking wx sample workspace, see here: codeblocks cbp projects for wx samples (https://forums.next.codeblocks.org/index.php/topic,25105.0.html)
While, after switch from one cbp to other cbp for many times, I got many clangd.exe process running, see the image shot below, is it correct?
Thanks.
Quote from: Pecan on September 16, 2022, 07:26:36 PM
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> ?
Quote from: ollydbg on September 17, 2022, 02:45:36 PM
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> ?
Thanks, I learned a long time ago that other eyes reviewing code can make it better.
Direct link to newer patch (https://sourceforge.net/p/codeblocks/tickets/_discuss/thread/92a1b2249a/e111/attachment/ccManagerMouseTrap220917-1.patch)
Patch for ticket #1168 applied in r12899, thank you.
The msys2 project now has clangd 15.0 for mingw64 targets.
I have a question:
LSP_ParseSemanticTokens(), what does this function used for?
I see this code:
// ----------------------------------------------------------------------------
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
The last line:
LSP_ParseSemanticTokens(symEvent); //Call directly
This use the our old-CC's parsing code, for example
// ----------------------------------------------------------------------------
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);
Quote from: ollydbg on September 25, 2022, 04:21:30 AM
I have a question:
LSP_ParseSemanticTokens(), what does this function used for?
The fastest way to satisfy a code completion request is to request the clangd "textDocument/DocumentSymbol" response.
However, that response does not have enough information to satisfy a code completion for a variable, enumeration, etc.
So clangd_client requests and parses the "textDocument/semanticTokens" record which does have variable info.
That response is very memory and process expensive. So we only use it when necessary (such as filling html Document popup info).
That particular response provides entries that need teasing out further info. The old CodeCompletion plugin has code to do that. I plan to use more of the old CodeCompletion parsing code in the future when needed.
Thanks for the explanation, I some times get error message like below when using clangd_client plugin:
Quote[Window Title]
Assert(non fatal)
[Content]
Trying to DoParse recursion in DoHandleClass():2028
[OK]
So, DoParse() is a function from old code completion plugin. :)
Quote from: ollydbg on September 16, 2022, 05:29:45 AM
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'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 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.
Quote from: ollydbg on September 28, 2022, 07:56:53 AM
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.
Quote from: ollydbg on September 28, 2022, 07:39:59 AM
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 ?
Quote from: Pecan on September 29, 2022, 12:36:37 AM
Quote from: ollydbg on September 28, 2022, 07:39:59 AM
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 ?
yes
sent from my phone
Quote from: Pecan on September 28, 2022, 04:52:16 PM
Quote from: ollydbg on September 28, 2022, 07:56:53 AM
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.
Quote from: ollydbg on September 29, 2022, 04:24:22 AM
Quote from: Pecan on September 28, 2022, 04:52:16 PM
Quote from: ollydbg on September 28, 2022, 07:56:53 AM
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.
Quote from: Pecan on September 29, 2022, 07:06:29 AM
Quote from: ollydbg on September 29, 2022, 04:24:22 AM
Quote from: Pecan on September 28, 2022, 04:52:16 PM
Quote from: ollydbg on September 28, 2022, 07:56:53 AM
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.
Thanks.
I disabled the clangd_client, and re-enabled the old CC plugin, and I don't see this issue in old CC plugin.
So, my guess it is caused by the clangd_client code.
EDIT:Maybe, the wrong CCCallTip
/** Structure representing an individual calltip with an optional highlighted range */
struct CCCallTipis returned from the clangd_client plugin?
EDIT2, this is the code to fill the m_SignatureTokens, which is the collection of CCCallTip.
// ----------------------------------------------------------------------------
// SignatureHelp event
// ----------------------------------------------------------------------------
else if ( evtString.StartsWith("textDocument/signatureHelp"))
{
Parser* pParser = (Parser*)GetParseManager()->GetParserByProject(pProject);
pParser->OnLSP_SignatureHelpResponse(event, m_SignatureTokens, m_HoverLastPosition);
}
Dear Pecan,
I'd like to highlight a possible issue with the new clangd pluging.
Look at the attached picture.
The function
void MainFrame::OnWriteA0( wxCommandEvent& event)
is reported (in both clangd toolbar and symbol browser) as
OnWriteA0wxCommandEvent & : void
without any separation character between OnWriteA0 and wxCommandEvent
Not a big problem but a little bit confusing. Is it possible to insert a space (for example) between the name of the function and the parameter?
Quote from: ollydbg on September 29, 2022, 04:24:22 AM
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)
Quote from: MaxGaspa on September 29, 2022, 11:11:45 PM
Quote from: ollydbg on September 29, 2022, 04:24:22 AM
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.
Quote from: ollydbg on September 30, 2022, 03:31:06 AM
Quote from: MaxGaspa on September 29, 2022, 11:11:45 PM
Quote from: ollydbg on September 29, 2022, 04:24:22 AM
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.
Quote from: Pecan on September 30, 2022, 06:15:35 AM
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.
See a minimal code below:
#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;
}
My guess is that it is an encoding/decoding error?
Here is the screen shot in attachment.
EDITIt looks like the comment after the variable definition cause this issue:
///< TCP接收的数据
If I remove this comment, the tooltip showns correctly.
The minimal sample can be simplified to:
int m_TcpFile; ///< TCP接收的数据
int main()
{
return 0;
}
I'm not quite understand the code, when I read the source code of clangd_client, I see this:
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));
}
I'm not sure, but it looks like:
wxString labelValue = signatures[labelndx].at("label").get<std::string>();
get<std::string>() should return a std::string.
Do we need to convert it to wxString?
OK, I think I have fixed this issue by using such patch:
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));
}
I'm not sure the second hunk is needed, but the first hunk is the true fix.
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:
wxString 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:
std::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.
Quote from: sodev on September 30, 2022, 08:22:14 PM
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:
wxString 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:
std::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.
Quote from: ollydbg on October 01, 2022, 01:47:51 AM
Quote from: sodev on September 30, 2022, 08:22:14 PM
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:
wxString 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:
std::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.
@sodev
@ollydbg
Thanks for this. I'll get to work checking every use of std::string to wxString in the source.
Clangd by default uses utf16. But it allows the use of utf8 as an option.
@ollydbg
Quote from: ollydbg on September 30, 2022, 09:14:17 AM
OK, I think I have fixed this issue by using such patch:
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));
}
I'm not sure the second hunk is needed, but the first hunk is the true fix.
@ollydbg
Would you test Clangd_Client rev 82 or the current nightly clangd_client to see if it solves the tooltip problem?
I've applied your fix for every clangd json std::string reference.
Example:
idValue = GetwxUTF8Str(pJson->at("id").get<std::string>());
GetwxUTFStr is defined as:
wxString GetwxUTF8Str(const std::string stdString)
{
return wxString(stdString.c_str(), wxConvUTF8);
}
Let me know if it works and thanks for testing.
Hi, pecan, thanks for the fix.
rev 82 works OK.
BTW, Is it possible to show the doxygen document in the tip window? Maybe, clangd already send to us? Thanks.
EDIT:
It looks like this clangd issue in github is related: Doxygen parsing missing Issue #529 clangd/clangd (https://github.com/clangd/clangd/issues/529)
I did some extra test of how to show the comments.
Here is the log file from CBclangd_client-xxxxx.log:
{"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}}}}
and here is the test code:
int m_TcpFile; ///< TCP接收的数据
int m_AAA; ///< ABCDEFG
int main()
{
return 0;
}
You can see, when I hover on the variable "m_TcpFile", the received json contains some wrong contents, I'm not sure why it is not shown in Chinese.
While, for the variable "m_AAA", it shows the "ABCDEFG" correctly.
EDIT
It looks like we just drop the text returned from clangd, after the second \n
Here is the screen shot(in attachment)
The source code looks like in parser.cpp line 2553
// 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));
@pecan,
I observed an unexpected behavior (i would say a bug) using the latest nightly and latest plugin. I'm observing the issue using both win7 SP1 or Win10 Enterprise.
After I opened a project the plugin started to parse the files starting from "62 more" ....in the meantime I launch the related executable (compiled before). The parser stopped. During the stopping phase the parser is parsing some files without updating the remaining file counter (repeating "59 more")
After closing the executable, the parser didn't restarted, It stayed sleeping. I used the option "Reparse the project" but the new parser was not starting. I opened one of the project's file (Main.cpp) and the parser parsed the opened file (restarting the remaining file counter from 66, not 62!!!! ( the previous starting number) but then stopped.
I closed Main.cpp and used several times "reparse the project" without success. I closed the project and the reopened it....the parser didn't start.
Then if I close CB and running a new CB loading the same projects used before I got the parser correctly parsing all files form 66 to 0.
I'm attaching the log from CB.
Hope this helps to reproduce the issue (It seems reproducible). I'm using 0 threads while compiling (and running?) and 6 threads concurrently parsing.
It seems there is some "memory" of the past parsing even if I delete the parser....
Max
I created a patch which can show the "doxygen comments".
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));
Normally, I see that
variable m_AAA\n\nType: int\nABCDEFG\n\nint m_AAA
There are 3 sections separated by "\n\n", first: "variable m_AAA", second: "Type: int\nABCDEFG", and third: "int m_AAA". Basically the first two sections are needed.
There is two ";" in the original statement, this should be fixed.
@pecan
I'm observing another issue using the clangd plugin.
Using a std::vector the list of functions shown are listed in alphabetical order but it seems there is a maximum number of list members. Look at the attached images, all the functions after max_size() are not listed. For example push_back() is not listed but if I write "push" after the dot the plugin is correctly suggesting push_back (look at the attached images).
So it seems that the plugin knows the function push_back() exists but is not showing in the full list.
Is there a way to increase the number of items in the list? Is that limitation intentional?
Quote from: ollydbg on October 04, 2022, 09:11:14 AM
I did some extra test of how to show the comments.
Here is the log file from CBclangd_client-xxxxx.log:
...
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.
int\nTCP鎺ユ敹鐨勬暟鎹甛n\nThe following patch solves this issue:
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);
Quote from: ollydbg on October 04, 2022, 01:21:01 PM
I created a patch which can show the "doxygen comments".
...
I think it again, and I think using the original text from the hover message is good enough. I think we don't need to "cut the chaff".
wxString hoverString = contentsValue;
Just show this, and I tested this method, and it works fine.
@pecan
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?
Quote from: MaxGaspa on October 09, 2022, 11:40:42 PM
@pecan
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?
Yes, I was finally able to replicate the issue and fix it in the new Nightly 221008.
https://forums.next.codeblocks.org/index.php/topic,25130.msg171351/topicseen.html#msg171351 (https://forums.next.codeblocks.org/index.php/topic,25130.msg171351/topicseen.html#msg171351)
To change the number of matched completions displayed use Settings/Editor/clangd_client/Maximum allowed code-completion matches.
I suggest you be conservative since the matches are cached, ie., taking up memory until new completions are requested.
Thanks for catching this and for testing.
Quote from: ollydbg on October 06, 2022, 03:36:18 AM
Quote from: ollydbg on October 04, 2022, 09:11:14 AM
I did some extra test of how to show the comments.
Here is the log file from CBclangd_client-xxxxx.log:
...
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.
int\nTCP鎺ユ敹鐨勬暟鎹甛n\n
The following patch solves this issue:
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);
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.
Quote from: Pecan on October 10, 2022, 06:41:29 AM
About my replay #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
Quote from: Pecan on October 10, 2022, 06:59:15 AM
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.
Hi, I have just tested this rev83. But it looks like the log still has some error Chinese chars. See the log below:
{"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}}}}
I see you have a function named:
std::string StdString_Format(const std::string fmt, ...)
I try to use this patch to avoid the function call, like:
-------------------- 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);
But I still got the same error result of Chinese chars. :(
Anyway, though the log file contains error Chinese chars, but the tip window shows correct Chinese words. (I'm showing the whole contents of the hoverString in the tip window)
// 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;
See image shot below in attachment.
Quote from: MaxGaspa on October 10, 2022, 11:17:39 AM
Quote from: Pecan on October 10, 2022, 06:41:29 AM
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
@MaxGaspa
Do NOT think that you bore me. I'm grateful for your help.
Thanks for reporting that the max completion matches list is fixed.
I have not yet had time to investigate the Pause/Sleep ("sleep state") bug.
I agree that it's a bug. I'll look at it very soon.
Quote from: ollydbg on October 10, 2022, 03:21:56 PM
But I still got the same error result of Chinese chars. :(
I guess in some stage, the original string(in UTF8) is still translated to the unicode string by my local encoding(GB2312, not the UTF8).
EDIT
// ----------------------------------------------------------------------------
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();
It looks like the wxFFile::Write only accept the wxString, but you passed the std:;string, so the wrong encoding is used for conversion.
Hi, Pecan, my guess is correct. ;)
-------------------- 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.
Quote from: ollydbg on October 11, 2022, 04:17:36 AM
Hi, Pecan, my guess is correct. ;)
-------------------- 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.
Quote from: Pecan on October 11, 2022, 06:36:51 AM
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.
Hi, Pecan, I think the using of member function Write from wxWidgets: wxFFile Class Reference (https://docs.wxwidgets.org/3.0/classwx_f_file.html):
bool Write (const wxString &str, const wxMBConv &conv=wxConvAuto())which is wrong here.
If you look at the source code, you will see:
// ----------------------------------------------------------------------------
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();
}
In this code, you first construct a std::string arg0:
arg0 = "\n" + GetTime_in_HH_MM_SS_MMM() + " " + logmsg + logcr
Then, the lspClientLogFile.Write() function need a wxString, so the arg0 is convert to wxString(arg0), and the bad thing is it will use the "Locale encodings", in my PC, it could be GB2312.
The wrong thing is: logmsg is returned from clangd, which is encoded in UTF8, and the implicit conversion from arg0 to wxString is using Locale encodings(GB2312).I think if you just need a byte stream, then we need another member function:
size_t Write (const void *buffer, size_t count)
This just
Writes the specified number of bytes from a buffer.
I hope you can understand my explanation.
Quote from: MaxGaspa on October 10, 2022, 11:17:39 AM
...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
@ MaxGaspa
Try the "-2" version below to see if it fixes the "sleep state" error.
It seems you've run across a CB bug where the "compiler finished" event was not being issued and clangd_client got stuck waiting for the compiler to end.
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.
Try:
https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/ClangdClientForCBNightly_221008_rev12969_win64-2.zip/download
(https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/ClangdClientForCBNightly_221008_rev12969_win64-2.zip/download)
@ olldbg RE: Reply #218 on: October 11, 2022, 02:44:26
Thanks, it works for me.
Will be in rev 85.
// ----------------------------------------------------------------------------
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();
Quote from: Pecan on October 14, 2022, 10:27:38 PM
@ olldbg RE: Reply #218 on: October 11, 2022, 02:44:26
Thanks, it works for me.
Will be in rev 85.
// ----------------------------------------------------------------------------
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();
Good work, this should the correct fix.
Hi, I'm building clangd_client rev84 with the latest C::B rev 12976.
Do I need to change the line to this:
// ----------------------------------------------------------------------------
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 line
//if (ns_CompilerEventId == XRCID("idCompilerMenuRun")) return;
Am I correct?
Quote from: ollydbg on October 15, 2022, 05:47:11 AM
Hi, I'm building clangd_client rev84 with the latest C::B rev 12976.
Do I need to change the line to this:
// ----------------------------------------------------------------------------
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 line
//if (ns_CompilerEventId == XRCID("idCompilerMenuRun")) return;
Am I correct?
You are correct. That fix is not needed with CB rev 12975 and above.
Thanks for testing.
Quote from: Pecan on October 14, 2022, 09:45:18 PM
I've made a temporary fix (until the next Nightly) that circumvents the missing event.
Be careful though, the circumvention allows clangd to parse files while the "Run" command is active. You might want to right-click on the project name and "Pause parsing(toggle)" before running your program from the menu run command.
After the "Run" finishes, you can "Pause parsing(toggle)" again to continue parsing where it left off.
@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
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:
limitedLogOut = 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().
Even I see there is a function call:
// 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
I think the content sent to the pipe is still in UTF8 encoding. (I just checked the code in src\winprocess\asyncprocess\winprocess_impl.cpp.
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;
}
<Partial quote>
Quote from: ollydbg on October 15, 2022, 12:56:32 PM
Hi, Pecan, In the latested r84 and with the change to using the std::string output of the both function writeClientLog() and writeServerLog().
I found an interesting thing that I got two different encoding output of the Chinese text in the comments.
One place is here, in the function: bool ProcessLanguageClient::WriteHdr(const std::string &in)
I see that the output of the content(usually the textDocument/didOpen message's content the client try to send to the LSP server) will be in GB2312 in my PC.
While, the content received from the server(usually the textDocument/hover message return from the LSP server) will be in UTF8 format.
I just exam the function body: bool ProcessLanguageClient::WriteHdr(), I see it still use the some kinds of std::string to wxString, and later some wxString to std::string, some conversion will use the default local encoding.
For example:
limitedLogOut = 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.
Quote from: MaxGaspa on October 15, 2022, 09:36:37 AM
Quote from: Pecan on October 14, 2022, 09:45:18 PM
I've made a temporary fix (until the next Nightly) that circumvents the missing event.
Be careful though, the circumvention allows clangd to parse files while the "Run" command is active. You might want to right-click on the project name and "Pause parsing(toggle)" before running your program from the menu run command.
After the "Run" finishes, you can "Pause parsing(toggle)" again to continue parsing where it left off.
@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
You can set the number of parsers you would like to run while compiling,running,debugging can be set at Settings/Editor/Clangd_client/"C/C++ parser"/Max number of threads while compiling.
But it really eats up the cpu. Set it to about 1/2 the number of processors/threads in your cpu.
Then sit back and feel it warm up the house and enjoy the aroma of melting plastic.
Quote from: Pecan on October 16, 2022, 01:57:16 AM
<Partial quote>
Quote from: ollydbg on October 15, 2022, 12:56:32 PM
Hi, Pecan, In the latested r84 and with the change to using the std::string output of the both function writeClientLog() and writeServerLog().
I found an interesting thing that I got two different encoding output of the Chinese text in the comments.
One place is here, in the function: bool ProcessLanguageClient::WriteHdr(const std::string &in)
I see that the output of the content(usually the textDocument/didOpen message's content the client try to send to the LSP server) will be in GB2312 in my PC.
While, the content received from the server(usually the textDocument/hover message return from the LSP server) will be in UTF8 format.
I just exam the function body: bool ProcessLanguageClient::WriteHdr(), I see it still use the some kinds of std::string to wxString, and later some wxString to std::string, some conversion will use the default local encoding.
For example:
limitedLogOut = 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.
Hi, Pecan, I just tested this rev 85, and I can confirm that the encoding issue is fixed. In the log file, both the textDocument/didOpen and textDocument/hover messages are showing the same UTF8 encoding now.
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.next.codeblocks.org/index.php/topic,25161.msg171549.html#msg171549)
But when I have only two plugins to load, in the debug-plugin.conf file, I have such content:
<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>
This means only those two dlls get loaded.
But when debugging, I see the debugee codeblocks will report that:
[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]
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:
<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>
Then, I can enable the clangd_client plugin correctly. (the codecompletion plugin should be loaded but disabled)
The situation is: if the codecompletion plugin never get loaded, I have no way to enable the clangd_client plugin. :(
I see another crash caught by GDB.
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)-
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.
Quote from: ollydbg on October 28, 2022, 12:40:23 PM
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.next.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'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.
Quote from: ollydbg on October 28, 2022, 03:25:13 PM
I see another crash caught by GDB.
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)-
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.
Fix applied in repo rev 87.
Thanks
Quote from: Pecan on October 31, 2022, 07:13:03 PM
...
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.
I can confirm this issue is fixed, thanks!
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
Quote from: killerbot on November 01, 2022, 03:40:19 PM
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
I'm comfortable with it now to say that it's ready to be added as a contrib.
I've used it everyday for more than a year.
If/when it become a contrib, it behaves/is guided by the presence of the old CodeCompletion plugin.
1) If CodeCompletion is enabled, Clangd_client disables itself.
2) If CB is a virgin install, and there's no compiler masterpath, Clangd_client disables itself.
3)If CodeCompletion is disabled, Clangd_client can run if the user enables it.
4)If CodeCompletion dll is missing, Clangd_client can run if the user enables it.
5) Otherwise, it remains asleep. waiting for user attention.
All these machinations are done to avoid any conflict with CodeCompletion and to give CodeCompletion priority. It requires the user to specifically take some actions:
1) Disable CodeCompletion and enable Clangd_client.
2) Provide a default compiler.
3) Provide access to a clang/clangd location (such as llvm or Msys).
I'll provide instructions in the CB wiki regarding it's use and requirements.
Andrew has already provided most of the work for that wiki entry.
But I'd like to hear how other users feel about it becoming a contrib.
Quote from: Pecan on November 01, 2022, 05:15:21 PM
...
...
But I'd like to hear how other users feel about it becoming a contrib.
+1.
I use clangd_client plugin in my daily work for several months, it works quite well.
It gives more accurate code suggestion, code reference, code-refactoring(rename) feature than the old code completion plugin.
I have maintained the old code completion plugin for many years. The C++ language and its grammar is becoming so complex nowadays, so we need a compiler level parser. Currently only clang based tool has this kinds of feature.
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)
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:
Quote from: ollydbg on November 05, 2022, 09:14:41 AM
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:
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.
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.
Quote from: ollydbg on November 05, 2022, 10:44:34 AM
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.
Quote from: Pecan on November 05, 2022, 09:37:37 PM
Quote from: ollydbg on November 05, 2022, 10:44:34 AM
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.
Hi, I'm sorry, this screen shot is from the code completion plugin, not from the clangd_client plugin. :(
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).
Quote from: ollydbg on November 05, 2022, 11:16:17 AM
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.
That may be true of the current clangd you're currently using.
But in previous versions (11 & 12), clangd was returning the wrong reference because it didn't distinguish between a declaration and a definition.
So I asked for both and chose the right one to display.
I'll revisit this some later time and make sure clangd is returning the actual request (definitions vs implementation).
Quote from: ollydbg on November 05, 2022, 11:16:17 AM
Quote from: ollydbg on November 05, 2022, 09:14:41 AM
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:
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.
I don't understand your patch.
The fix according to the jacob slusser quote is to use GetColumn().
But your patch uses fauxColumn instead.
Jacobslusser quote:
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);
Quote from: ollydbg on November 06, 2022, 11:30:05 AM
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).
I can't re-create the error after many tries, but I think I've experienced this.
So I'll have to insert some code to try and catch it.
I'll enter this as a ticket @clangd_client repo so it doesn't get lost.
@ollydbg
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.
Quote from: Pecan on November 06, 2022, 09:13:59 PM
@ollydbg
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.
It's good that you can reproduce it.
I just prepared the test code, it is very simple:
int 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:
Quote from: ollydbg on November 07, 2022, 02:09:09 AM
It's good that you can reproduce it.
I just prepared the test code, it is very simple:
int 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:
@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/
I'm trying to update clangd_client as a contrib.
On Linux after I run:
cd trunk
./bootstrap
./configure
make
How do I know if it worked or not.
I don't see any make output even though it looks like it ran without errors.
Am I supposed to have .o files or something?
Edit 13:45
I see there was produced the following:
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
But nothing for any contribs. Is this normal?
If so, how do I produce .libs for the contribs (just to see if I'm on the right track)?
Quote from: Pecan on November 08, 2022, 07:30:09 AM
......
@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/
Hi, thanks for the fix, I just test the rev88, and it works quite well. I see you have extra fixes in the "rename" event handling.
When editing the "#include <" or other statement, I see an annoying messagebox, I just translate the messagebox to log:
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
BTW: I really do not know why this happens, do you want to parse a single line using the hand written parser ourselves?
Quote from: ollydbg on November 09, 2022, 02:49:06 AM
...
When editing the "#include <" or other statement, I see an annoying messagebox, I just translate the messagebox to log:
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
BTW: I really do not know why this happens, do you want to parse a single line using the hand written parser ourselves?
I'll make that annoying cbMessageBox into a log msg instead.
#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
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
If There are no objections, I'd like to commit Clangd_client as a contrib.
It runs fine on both Windows and Linux.
And I believe Andrew has it working on Mac.
Thanks
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
Conversely, clangd_client_wx32.cbp is missing although CodeBlocks_wx32.workspace includes it (ticket #1327).
File clangd_client_wx31.cbp has this linker option:
<Add option="-m64" />
but it is a 32-bit project.
Quote from: gd_on on November 14, 2022, 02:04:13 PM
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
I don't know how to control that header version number, but the code for rev 88 is included with the contrib commit.
CodeBlocks_wx32_64.workspace corrected; Thanks.
The documentation-install folder was left out on purpose and will be included in the CB wiki for Clangd_client so we can just refer to the wiki url to answer questions. A new section will be added for just "using" the plugin vs "compiling from source.
Thanks
OK.
Nevertheless I see at least four differences :
- in version.h, probably not very important (svn version number)
- in manifest.xml, here too not very important (svn version number)
- in codecompletion.cpp, here too not very important (revision number in the headers)
- in LSP_symbolsparser.cpp, small differences near line 2200. I don't know if it's important
There are other differences but only in $HeadURL lines, so no problems.
Quote from: Miguel Gimenez on November 14, 2022, 04:16:26 PM
File clangd_client_wx31.cbp has this linker option:
<Add option="-m64" />
but it is a 32-bit project.
Fixed rev 13031. Thanks
Quote from: Miguel Gimenez on November 14, 2022, 02:30:42 PM
Conversely, clangd_client_wx32.cbp is missing although CodeBlocks_wx32.workspace includes it (ticket #1327).
Fixed rev 13031. Thanks
Thank you for the fix. The new clangd_client_wx32.cbp has some issues:
<Add option="-m64" /> and <Add option="-D_WIN64" /> in compiler options.
References to devel32_64 and .objs32_64
Global variables use #WX32_64
[r12032] fixed most issues, but this compiler options are still invalid for a 32-bit project.
<Add option="-m64" />
<Add option="-D_WIN64" />
Quote from: Miguel Gimenez on November 14, 2022, 07:46:55 PM
[r12032] fixed most issues, but this compiler options are still invalid for a 32-bit project.
<Add option="-m64" />
<Add option="-D_WIN64" />
Thanks, fixed in rev 13033
*.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?.
Quote from: Miguel Gimenez on November 15, 2022, 12:09:48 PM
*.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?.
Fixed in commit CB rev 13035
.depend was already in the ignore list.
Added .layout to ignore list.
Added clangd_client.zip to the ignore list
Made corrections to clangd_client_wx30.cbp
Thanks
The .depend is still "active", after compiling the plugin:
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
so *.depends is missing. Other folders (p.e. src/src) add also *_build_log.html, because saving build log to HTML leaves this files around.
IMHO the ignore list should be:
Properties on '.':
svn:ignore
*.depend
*.layout
*_build_log.html
clangd_client.zip
Quote from: Miguel Gimenez on November 16, 2022, 11:45:10 AM
The .depend is still "active", after compiling the plugin:
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
so *.depends is missing. Other folders (p.e. src/src) add also *_build_log.html, because saving build log to HTML leaves this files around.
IMHO the ignore list should be:
Properties on '.':
svn:ignore
*.depend
*.layout
*_build_log.html
clangd_client.zip
Please go ahead and change them as you see fit.
I've read "svn propset -h" three times now, and I still can't figure out how to set ignores.
QuotePlease go ahead and change them as you see fit.
Done. Just go to the plugin directory and write:
svn propedit svn:ignore .
Quote from: Miguel Gimenez on November 17, 2022, 07:46:57 AM
QuotePlease go ahead and change them as you see fit.
Done. Just go to the plugin directory and write:
svn propedit svn:ignore .
The result of this is:
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
It wants me to set some editor like:
set SVN_EDITOR=notepad.exeThen, running the svn command brings up notepad with the svn:ignore file settings.
I suppose I'm suppose to save it. But who knows....
[rant]Some day I hope to trash svn. It trades intuitiveness for utter confusion plus hours and hours to try and understand it.
[/rant]
Quote from: Pecan on November 09, 2022, 06:36:27 PM
....
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;
};
To reproduce this issue, you can
first put the caret after the line "/// comment", and just continuously hit the Enter key several times.
@Pecan
You are using Windows, you simply don't use cli tools on Windows :P. Install https://tortoisesvn.net/ (https://tortoisesvn.net/) for your SVN needs.
today I tried to activate it on my linux box, I first disabled first the regular code completion plug-in, shutdown CB, started CB, then enabled the clangd based plug-in, which suggest me again to close and restart CB, so I did that.
When CB starts up again, it gives me an informational error message, to set the path of the clangd executable but the moment I open up settings-> Editor CB crashes, and I am never able to set it.
Below a snippet from the crash stack:
<stack>
<frame level="0" function="CodeBlocksApp::OnFatalException()" offset="00000000"/>
<frame level="1"/>
<frame level="2"/>
<frame level="3" function="wxSpinCtrlGTKBase::DoSetValue(double)" offset="00000000"/>
<frame level="4" function="CCOptionsDlg::CCOptionsDlg(wxWindow*, ParseManager*, ClgdCompletion*, DocumentationHelper*)" offset="00000ba0"/>
<frame level="5" function="ClgdCompletion::GetConfigurationPanel(wxWindow*)" offset="0000004b"/>
<frame level="6" function="PluginManager::GetConfigurationPanels(int, wxWindow*, ConfigurationPanelsArray&, cbConfigurationPanelColoursInterface*)" offset="00000165"/>
<frame level="7" function="EditorConfigurationDlg::AddPluginPanels()" offset="00000000"/>
<frame level="8" function="EditorConfigurationDlg::EditorConfigurationDlg(wxWindow*)" offset="00000000"/>
<frame level="9" function="MainFrame::OnSettingsEditor(wxCommandEvent&)" offset="00000000"/>
<frame level="10" function="wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)" offset="0000006e"/>
<frame level="11" function="wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)" offset="00000073"/>
<frame level="12" function="wxEvtHandler::TryHereOnly(wxEvent&)" offset="0000004b"/>
<frame level="13" function="wxEvtHandler::DoTryChain(wxEvent&)" offset="00000043"/>
<frame level="14" function="wxEvtHandler::ProcessEvent(wxEvent&)" offset="00000039"/>
<frame level="15" function="wxWindowBase::TryAfter(wxEvent&)" offset="00000052"/>
<frame level="16" function="wxEvtHandler::SafelyProcessEvent(wxEvent&)" offset="00000007"/>
<frame level="17" function="wxMenuBase::SendEvent(int, int)" offset="0000009b"/>
from the conf file
<clangd_client>
<PARSER_DEFAULTS_CHANGED bool="1" />
<PARSER_FOLLOW_LOCAL_INCLUDES bool="1" />
<PARSER_FOLLOW_GLOBAL_INCLUDES bool="1" />
<WANT_PREPROCESSOR bool="1" />
<PARSE_COMPLEX_MACROS bool="1" />
<PLATFORM_CHECK bool="1" />
<SPLITTER_POS int="250" />
</clangd_client>
maybe I can manually add it here, what's the directive ?
EDIT: added
<LLVM_MASTERPATH>
<str>
<![CDATA[/opt/llvm/bin/clangd]]>
</str>
</LLVM_MASTERPATH>
still crashes as hard
@Killerbot
Tomorrow (dec 13) I'll run through your described steps and see if I can catch the crash. Looks like it might be in a config option I've not tested on linux.
Quote from: killerbot on December 11, 2022, 10:52:39 AM
today I tried to activate it on my linux box, I first disabled first the regular code completion plug-in, shutdown CB, started CB, then enabled the clangd based plug-in, which suggest me again to close and restart CB, so I did that.
When CB starts up again, it gives me an informational error message, to set the path of the clangd executable but the moment I open up settings-> Editor CB crashes, and I am never able to set it.
... edited ...
@Killerbot
I've tried for many hours to re-create this error on both Linux Mint20.2 and WSL2 with no success.
I've uploaded a video of a Mint20.2 run at
https://www.dropbox.com/s/d6lhsxbzi64x9cr/ClangdClientVideo_221214.zip?dl=0
The zip file contains a .wmv which played on both my windows and Mint systems, but not on my WSL2 (WSL2 requires a whole bunch of additional install fooey).
Note: I used a virgin CB profile (.conf) to do testing, but I only have gtk3 (64bit) to test with. So I couldn't try testing with gtk2.
We might get closer to the error if you would do the following.
Compile clangd_client with -g set to get debug symbols.
Run CB in the debugger and perform the steps you performed to get the error. Then lets have a look at the backtrace.
If debugging is not an option, just copy the -g compiled devel32_64 version of clangd_client dll into your output32_64 plugin folder and perform the steps that caused the error.
You should then get a .rpt file in the output32_64 folder which will have the statement that caused the crash.
Try doing all the above with a virgin personality, eg "run.sh -p virginConf"
If it runs with the virgin conf, we'll know it has something to do with the .conf contents.
In all your spare time :>) you might have a look at:
https://wiki.codeblocks.org/index.php/CB_Clangd_Client
to see if anything was missed there (but I doubt it has anything to do with this crash).
Thanks
Quote from: killerbot on December 11, 2022, 10:52:39 AM
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
Quote from: Pecan on December 15, 2022, 10:23:36 PM
Quote from: killerbot on December 11, 2022, 10:52:39 AM
today I tried to activate it on my linux box, I first disabled first the regular code completion plug-in, shutdown CB, started CB, then enabled the clangd based plug-in, which suggest me again to close and restart CB, so I did that.
When CB starts up again, it gives me an informational error message, to set the path of the clangd executable but the moment I open up settings-> Editor CB crashes, and I am never able to set it.
Below a snippet from the crash stack:
... snipped ...
Finally managed to catch the crash.
Fixed in Head rev 13120.
Thanks
Good work, I once see your changes in rev 13120.
src/plugins/contrib/clangd_client/src/codecompletion/codecompletion.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/plugins/contrib/clangd_client/src/codecompletion/codecompletion.cpp b/src/plugins/contrib/clangd_client/src/codecompletion/codecompletion.cpp
index cd42a081..22d40c47 100644
--- a/src/plugins/contrib/clangd_client/src/codecompletion/codecompletion.cpp
+++ b/src/plugins/contrib/clangd_client/src/codecompletion/codecompletion.cpp
@@ -2895,7 +2895,6 @@ void ClgdCompletion::OnAppStartupDone(CodeBlocksEvent& event)
msg << _("\n\nDo you want to use the detected clangd?");
wxWindow* pTopWindow = GetTopWxWindow();
- cbMessageBox(msg, _("ERROR: Clangd client"), wxOK, pTopWindow);
if (cbMessageBox(msg, _("ERROR: Clangd client"), wxICON_QUESTION | wxYES_NO, pTopWindow) == wxID_YES)
{
cfg->Write(_T("/LLVM_MasterPath"), fnClangdPath.GetFullPath());
Maybe, you can add a comment on the pTopWindow, because the next line, there is still a cbMessageBox() function call.
But that function does allow passing a nullptr pTopWindow pointer as the last argument.
gone test the fix soon. Note on the other hand since manually adding this path, I do think the plug-in is doing stuff, since i get information as tooltips.
still happens
<frame level="0" function="CodeBlocksApp::OnFatalException()" offset="00000000"/>
<frame level="1"/>
<frame level="2"/>
<frame level="3" function="wxSpinCtrlGTKBase::DoSetValue(double)" offset="00000000"/>
<frame level="4" function="CCOptionsDlg::CCOptionsDlg(wxWindow*, ParseManager*, ClgdCompletion*, DocumentationHelper*)" offset="00000ba0"/>
<frame level="5" function="ClgdCompletion::GetConfigurationPanel(wxWindow*)" offset="0000004b"/>
<frame level="6" function="PluginManager::GetConfigurationPanels(int, wxWindow*, ConfigurationPanelsArray&, cbConfigurationPanelColoursInterface*)" offset="00000165"/>
<frame level="7" function="EditorConfigurationDlg::AddPluginPanels()" offset="00000000"/>
<frame level="8" function="EditorConfigurationDlg::EditorConfigurationDlg(wxWindow*)" offset="00000000"/>
<frame level="9" function="MainFrame::OnSettingsEditor(wxCommandEvent&)" offset="00000000"/>
<frame level="10" function="wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)" offset="0000006e"/>
<frame level="11" function="wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)" offset="00000073"/>
other questions, what should functions calling 'foo' do, it gives me nothing and opens u[ the tab at the bottom of cscope ?
Quote from: killerbot on December 16, 2022, 05:47:30 PM
other questions, what should functions calling 'foo' do, it gives me nothing and opens u[ the tab at the bottom of cscope ?
Geez, I have no idea what you're referring to.
What do you mean by "function calling "foo" ?
What do you mean by "bottom of cscope" ?
clangd_client has nothing to do with whatever that is.
Could you show us a list of the plugins you're running? I'll try to configure like your plugin setup.
I'm leaning toward believing we have a plugin conflict here.
Quote from: killerbot on December 16, 2022, 05:43:29 PM
still happens
<frame level="0" function="CodeBlocksApp::OnFatalException()" offset="00000000"/>
<frame level="1"/>
<frame level="2"/>
<frame level="3" function="wxSpinCtrlGTKBase::DoSetValue(double)" offset="00000000"/>
<frame level="4" function="CCOptionsDlg::CCOptionsDlg(wxWindow*, ParseManager*, ClgdCompletion*, DocumentationHelper*)" offset="00000ba0"/>
<frame level="5" function="ClgdCompletion::GetConfigurationPanel(wxWindow*)" offset="0000004b"/>
<frame level="6"
... snipped ...
Hail Mary pass rev 13122.
That spinCtrl is the first item in the clangd_client .xrc files that changed from the CC xrc files. Is that a clue or what?
I've now change all the
class="wxPanel" name=<> names to be different for those in the CC xrc files which I shamelessly copied from CodeCompletion plugin. I think doing that just bit me in the butt.
I'm guessing that CB did NOT load the clangd_client xrc files
for Killerbots version of Linux because the main wxPanel had the same name as the CC main wxPanel.
I can hear it in my head. CB says: "Oh hell. I don't have to load that crap; the panel name's the same as the one I loaded for CC. Let 'em eat that."
Give it another try Killerbot. I'm holding my fingers crossed.
Just for my education, what version of Linux are you using?
Is it the same one you were using in 2005 ? :>)
Thanks
it is fixed :-)
my OS :
cat /etc/os-release
NAME="openSUSE Leap"
VERSION="15.4"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.4"
PRETTY_NAME="openSUSE Leap 15.4"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.4"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Leap"
LOGO="distributor-logo-Leap"
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 ?
Quote from: killerbot on December 16, 2022, 11:07:16 PM
on the other topic :
When you right click on a function/class method (say it is called 'foo'), you can select : Find functions calling 'foo'
I would assume this comes also from the CC plug-in ?
This opens up the tab of the plug-in cscope (or maybe this is from cscope ??), and I jumped to conclusion the (clangd based) CC plug-in does that ?
The "Find functions calling 'foo'" is not from the clangd_client plugin. I guess it is from the cscope plugin.
Quote from: ollydbg on November 06, 2022, 11:30:05 AM
I have some situation that there are many information messages showing: LSP: File not yet parsed.
The step is:
1, double click on a file in the source navigation tree, and a new editor is opened.
2, mouse hover on some symbols in the editor.
3, the information massage happens.
Sometimes, I got this information messages showing many times, I think there is a logic error.
... quote modified by pecan ...
Finally !! Caught and fixed in Head rev 13134
It seems clangd server started (at some point) sending an empty textDocument/publishDiagnostics
response (with a missing "version" entry) to a didClose() request, which really confused clangd_client.
Thanks ollydbg :>)
Quote from: Pecan on December 24, 2022, 08:39:19 PM
Quote from: ollydbg on November 06, 2022, 11:30:05 AM
I have some situation that there are many information messages showing: LSP: File not yet parsed.
The step is:
1, double click on a file in the source navigation tree, and a new editor is opened.
2, mouse hover on some symbols in the editor.
3, the information massage happens.
Sometimes, I got this information messages showing many times, I think there is a logic error.
... quote modified by pecan ...
Finally !! Caught and fixed in Head rev 13134
It seems clangd server started (at some point) sending an empty textDocument/publishDiagnostics
response (with a missing "version" entry) to a didClose() request, which really confused clangd_client.
Thanks ollydbg :>)
Hi, thanks, I will rebuild my C::B and test it.
EDIT:It looks there is a typo in this commit.
-#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.
Quote from: ollydbg on December 28, 2022, 09:43:03 AM
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.
That's how clangd works.
Clangd doesn't seem to distinguish between the declaration and definition. It only has a "GoToDefinition" request.
If there's a missing .h or .cpp file, Find Declaration and Find Implementation mean the same thing to clangd.
I've tried adding code to determine which to display.
Given the request came from an .h file I try to display the .cpp file entry and vise versa.
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 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 ?
QuoteI 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
found it, thanks.
Quote from: Pecan on December 28, 2022, 08:24:34 PM
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:
#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.
Quote from: ollydbg on January 08, 2023, 04:03:46 AM
Quote from: Pecan on December 28, 2022, 08:24:34 PM
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:
#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 ?
Glad you made it through covid. I know how awful that suff is. I got it before there was any vaccine. It's dangerous.
Quote from: Pecan on January 09, 2023, 06:22:50 PM
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.
If you split them in a .h and .cpp file, you will jump between the two files.
Quote
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!
Quote from: ollydbg on December 28, 2022, 09:43:03 AM
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.
Quote from: Pecan on January 14, 2023, 10:28:10 PM
Quote from: ollydbg on December 28, 2022, 09:43:03 AM
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.
Thanks, especially for your time and effort to try to fix the issue. I just add one comment on that clangd github issue.
Here are my guess:
To distinguish the definition and declaration. If we have to two locations: one in header file and the other in implementation file. This means the former is the declaration and the later is the definition.
If we can't distinguish by the file extension, then I guess the declaration have the ";" at the end of the statement, and the definition usually don't. Maybe a function definition may have a "{" at the beginning. (I think this is the way our build-in C++ parser parses the file, maybe ctags universal-ctags/ctags: A maintained ctags implementation (https://github.com/universal-ctags/ctags), the one used in CodeLite for its native C++ parser also did that similar things.)
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...
Quote from: BlueHazzard on February 26, 2023, 12:38:47 AM
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...
For me this happens after running the debugger.
Clangd_client is paused when running the debugger, but it didn't solve the problem. I'll keep working on it.
You can right-click in the editor and select "Reparse this file" or right-click on the project in the workspace tree and select "Reparse this project" to solve the problem.
I'll move the messages to the log as you suggest.
Thanks for the report.
It tells me that it's not just my machine that's having this problem.
Quote from: BlueHazzard on February 26, 2023, 12:38:47 AM
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...
This should be fixed in Head 13230.
Clangd_client now puts a msg in the log and issues an Info msg that the file is being reparse.
I cannot find a way to re-create the problem. So if it happens, let me know if the fix is working ok.
Thanks
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
Quote from: killerbot on March 19, 2023, 11:12:01 PM
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
Tell me how you installed it so I can do the same and reproduce the error.
I build it like this :
sudo rm -rf /opt/llvmTemp
rm -rf llvm-project
git clone --branch llvmorg-16.0.0 --depth=1 https://github.com/llvm/llvm-project.git
cd llvm-project
sed -i 's/set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default ON)/set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default OFF)/g' ./llvm/runtimes/CMakeLists.txt
mkdir build
cd build
cmake -G Ninja -DCMAKE_BUILD_TYPE=RELEASE -DCMAKE_INSTALL_PREFIX=/opt/llvmTemp -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld;lldb;openmp" -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind;compiler-rt" ../llvm
ninja
sudo ninja install
#sudo 'echo "/opt/llvm/lib" > /etc/ld.so.conf.d/clanglib.conf' \
sudo ldconfig
note the echo line, you need to do this at least once, and off course also add /opt/llvm/bin yo your PATH
Quote from: killerbot on March 19, 2023, 11:12:01 PM
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
Fixed svn Head rev 13241.
@Killerbot
Thanks for the instructions.
the fix works for me using Windows sublayer for Linux(WSL). Let us know if it works in your environment.
The problem was: The clangd version (16.0.0) no longer matches the clangd resources lib name (...\lib\clang\16\).
The version number used to be appended to the lib dir name.
confirmed solved,
and indeed on my 15.0.7 the dir is called /opt/llvm/lib/clang/15.0.7/
let's see when 16.0.1 comes ....
Hi!
I've recently started to work with SMT32 microcontrollers, and I discovered that standard Code::Blocks's code completion plugin doesn't work very well in some specific cases like this one:
#define GPIOA ((GPIO_TypeDef *) GPIOA_BASE)
GPIOA_BASE is not recognized correctly as a pointer to the structure of type GPIO_TypeDef, and Code::Blocks doesn't give any autocomplete suggestions after I type "GPIOA_BASE->" (see https://forums.next.codeblocks.org/index.php/topic,21823.0.html). So I decided to try this plugin.
So I installed the latest nightly build (06 May 2023 build (13268)) of C::B and clangd 16.0.2. Then I disabled the original code completion plugin, enabled clang_client and set the path to the clang executable. But when I tried to open my STM32 project, I got an error message (see the attached screenshot). It is obvious that there was some encoding problem caused by Cyrillic characters in the project path. Usually in such cases I create symbolic links/directory junctions with appropriate English-only directory names, but in this case I can't fix the problem this way because clangd doesn't work great with symlinks.
I decided to download the sources of C::B and plugins and try to fix the problem myself. And I think I managed to get it to work correctly. I've changed the file plugins/contrib/clangd_client/src/LSPclient/client.cpp. Here is the diff output:
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());
I'm not sure if I've done it right, but it seems that the plugin is working fine. Maybe this information will be helpful for the further development of the clangd-client plugin.
Best regards,
Arseniy.
P.S. Thank you @Pecan and the other developers who works on this plugin. It's a great idea to integrate C::B with clangd!
@ Trigger
Your fix applied in head rev 13271. Thanks.
Continuation of discussion from:
https://forums.next.codeblocks.org/index.php/topic,25383.msg173164.html#msg173164
Quote from: myztmy on June 07, 2023, 10:13:11 AM
Quote from: Pecan on June 07, 2023, 06:45:52 AM
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 messages
LSP 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)|
......
......
@ myztmy
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
Quote from: Pecan on June 07, 2023, 06:26:06 PM
@ myztmy
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
Quote from: myztmy on June 09, 2023, 09:53:36 AM
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.
Quote from: Pecan on June 10, 2023, 07:09:46 PM
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.
Following is my codes
main.cpp
//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;
}
test.h
#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_Htest.cpp
#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; }
Please refer to the attached image in my previous post for the project structure ,in fact that image have shown nealy all code .
I feel very sorry for publishing such simple code too late, but if it is useful to you, I hope it can retain your step 8).
Regards
@ 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.
Because there was a major leak in clangd_client, now fixed, users of this plugin should update from Head rev 13343.
It will also be in the next Nightly.
Thanks, Christo, for catching this, and for the fix.
I see an alert when I enabled the Clangd_client, and when I hit the dot after I type an object name.
obj.
That means the code suggestion list about the object's member variables will be prompted.
Here is the screen shot of the alert. Do you know what cause this alert? Thanks.
EDIT: after I click the "continue" button, C::B just crashed. :(
EDIT2
I see the crash log in the RPT file:
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
EDIT3:
I'm using the latest svn version under Windows.
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:
Quote from: ollydbg on September 25, 2023, 10:09:17 AM
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.
Quote from: ollydbg on September 25, 2023, 10:24:25 AM
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.
Quote from: Pecan on September 25, 2023, 08:11:47 PM
Quote from: ollydbg on September 25, 2023, 10:09:17 AM
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.
OK, I will do that. Thanks.
Quote
Also, can you give an example code so I can reproduce the error.
I can't reproduce it yet.
I will try to minimize the project, my project is huge. Currently I can't reproduce this bug easily. :(
Quote from: Pecan on September 25, 2023, 09:54:59 PM
Quote from: ollydbg on September 25, 2023, 10:24:25 AM
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.
I use C::B for development day by day for many years. :)
If we have iron shown, I think we can distinguish between member variables and member functions.
About the line 2582 issue, let me rebuild the whole C::B again. EDIT:I may have some local patch here for Windows font related issue.
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);
}I see the line 2582 is the line above, the line begins with "wxCHECK_RET".
@ ollydbg
For me, platwx.cpp liine 2582 is blank.
Head rev 13361
Can you make the problem occur with the -g version of clangd_client.dll ?
It would show us exactly what's happening, even with your modified code.
@ollydbg
Note the code below: has only two calls to Append(...)
The first has a definition that defaults type=-1, and the second, when called, has a hard coded type=-1 (platWX.cpp line:2571) set by SetList() before the calling Append().
So it appears that an additional call has been added to your code that sets type to something other than -1 before calling the first Append(...) which calls the second Append().
Maybe that will help find it.
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.
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.next.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
Quote from: ollydbg on September 27, 2023, 04:54:19 PM
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.
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.next.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
@ollydbg
After many hours, I cannot re-create the error.
Then the only action left is to run both CodeBlocks and clangd_client in "-g" mode in order to catch the assert/crash.
Just copy the devel32_64 versions of them to your release folder after running update32_64.bat.
When the assert happens, click continue and you should get a .RPT with all the line numbers in the backtrace.
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.
Quote from: ollydbg on October 22, 2023, 04:32:21 AM
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.
Yes, I've experienced this. But it may not have anything to do with Clangd_client.
I think it's a problem in BrowseTracker itself.
I'll look into it.
Thanks for the report.
@ ollydbg
Quote from: ollydbg on October 22, 2023, 04:32:21 AM
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.
@ ollydbg
Would you place the following "return;" mod in JumpTracker.cpp and see if it solves this problem for you.
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
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.
Quote from: Pecan on October 23, 2023, 06:34:24 PM
@ ollydbg
Would you place the following "return;" mod in JumpTracker.cpp and see if it solves this problem for you.
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
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!
Quote from: ollydbg on October 24, 2023, 02:18:32 AM
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
Quote from: Pecan on October 24, 2023, 06:19:59 PM
Quote from: ollydbg on October 24, 2023, 02:18:32 AM
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
Good work! Thanks!
@pecan
QuoteThe 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.
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.
Quote from: gd_on on October 26, 2023, 05:42:13 PM
<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.
I'll have a look at it.
It'll take some time. Clangd reports types (kinds) entirely differently from legacy CodeCompletion. I don't yet know how to map Clangd kinds to the legacy icons.
Today, I got a crash when I'm editing in C::B, see the call stack here, (from the codeblocks.RPT file)
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
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.
Quote from: ollydbg on November 12, 2023, 04:32:47 AM
Today, I got a crash when I'm editing in C::B, see the call stack here, (from the codeblocks.RPT file)
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
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.
Update to at least rev 13390.
I think this is already fixed.
Thanks for the report.
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.
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);
As 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 .
Thanks, Christo
Quote from: Pecan on November 12, 2023, 06:53:39 AM
Update to at least rev 13390.
I think this is already fixed.
Thanks for the report.
I think I still catch a crash bug several minutes ago, see the call stack below, I'm using the latest rev13394.
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
The line 921 is at this line:
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:
{
Quote from: christo on November 13, 2023, 07:32:33 PM
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.
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);
As 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 .
Thanks, Christo
OK, I'll investigate. But after I find the reason for a ClassBrowser crash.
@ 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.
Quote from: Pecan on November 14, 2023, 08:40:44 PM
@ 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.
Yes, I have the document popup option on.
I will try to turn it off to see whether such crash happens again.
@ 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
Quote from: Pecan on November 15, 2023, 01:16:52 AM
@ 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
Thanks, I will do it in a few hours. In fact, I use C:B as my main development environment, so I use it every day.
Quote from: Pecan on November 14, 2023, 07:54:22 PM
OK, I'll investigate. But after I find the reason for a ClassBrowser crash.
Hi Pecan, please ignore issue I raised with query-driver, it happened due to an invalid compiler [YOUR ANSWER IS ALREADY THERE. SEARCH THE FORUMS!] configuration. On correcting that everything works as expected. Thank you
@ Christo: thanks.
@ olldbg
Sorry to keep you dancing like this but... 8>}
Would you reupdate to rev 13397.
While tracing the crash, I found other code that could cause re-entry into ClassBrowserBuildThread while it was busy.
This time, it's not a guess; I actually caught it and coded a fix that avoids the double entry.
Remember to copy Clangd_client dll from devel32_64 to output32_64 in case I'm full of (you know what); so that we can get line numbers on crashes.
TLDR:
Every time an editor is activated (happens every time the mouse moves into the text), it calls UpdateClassBrowser(). I should have known this, but my brain is old and rusting. And every 4th time a parser finishes a translation unit it invokes UpdateClassBrowserView(). Those two can happen at the same time. So I've moved busy checks just inside those functions to catch thread "busy" as soon as possible so one doesn't mod the TokenTree while the other is doing its business.
Clangd_client uses TryLocks(250 mil). If the lock fails, it was requeuing an idle time callback for the ClassBrowser update . I've remove these (for the time being) in case they were exacerbating the situation. Code now just skips the update.
I think I'll leave it that way until after the coming release.
There seems to be enough editor activating and background parsing to drive the update.
I haven't found any disadvantage so far.
Thanks !!
Hi, Pecan, thanks. I appreciate your work on the clangd_client plugin.
I'm using the rev 13397 for about 6 hours, and I haven't see a crash here till now. :)
Quote from: ollydbg on November 16, 2023, 10:09:29 AM
Hi, Pecan, thanks. I appreciate your work on the clangd_client plugin.
I'm using the rev 13397 for about 6 hours, and I haven't see a crash here till now. :)
I came across the post, and I wonder if you were able to implement what you wrote about?
https://forums.next.codeblocks.org/index.php?topic=17543.0 (https://forums.next.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)?
Quote from: omlk on November 16, 2023, 02:15:14 PM
Quote from: ollydbg on November 16, 2023, 10:09:29 AM
Hi, Pecan, thanks. I appreciate your work on the clangd_client plugin.
I'm using the rev 13397 for about 6 hours, and I haven't see a crash here till now. :)
I came across the post, and I wonder if you were able to implement what you wrote about?
https://forums.next.codeblocks.org/index.php?topic=17543.0 (https://forums.next.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.
Clangd_client only references the TokenTree with a mutex trylock. If it cannot obtain the lock it reschedules access to the TokenTree until it can obtain the lock.
Clangd_client works slightly slower than lagacy CC in that it uses the a Clangd LSP server to do all parsing of translation units (TU). It does no language parsing itself.
Its advantage is that it supports C++ versions as fast as the Clangd LLVM team can release Clangd support for that new C/C++ version.
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.
For inistallation info see https://wiki.codeblocks.org/index.php/CB_Clangd_Client
Quote from: Pecan on November 16, 2023, 07:20:44 PM
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
Quote from: omlk on November 16, 2023, 07:59:27 PM
Quote from: Pecan on November 16, 2023, 07:20:44 PM
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
Depends on what you mean by a local network.
Clangd_client and Clangd LSP server are all in the same machine communicating with pipes.
I'm not interested in arguments about clang use.
Clangd uses the parser, not the compiler.
CodeBlocks needs a modern parser for C++11 and beyond.
You don't have to use it.
Now it will be necessary to monitor what and how clang transmits over the network :)
Wireshark now officially support msys2 to compile in Windows https://www.wireshark.org/news/20231115b.html
Quote from: Pecan on November 16, 2023, 07:20:44 PM
Quote from: omlk on November 16, 2023, 02:15:14 PM
Quote from: ollydbg on November 16, 2023, 10:09:29 AM
Hi, Pecan, thanks. I appreciate your work on the clangd_client plugin.
I'm using the rev 13397 for about 6 hours, and I haven't see a crash here till now. :)
I came across the post, and I wonder if you were able to implement what you wrote about?
https://forums.next.codeblocks.org/index.php?topic=17543.0 (https://forums.next.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.
@omlk
The COW strings issue. If I member correctly, recent GCC's std::string and wxString do not use the COW(copy on write). So, I think this issue is gone. Because the COW has many issue on multiple thread environment.
About the old legecy CodeCompletion plugin, the parser in this plugin has all hand written. But the modern C++'s grammar is very complex to parse, the parser failed to parse the source files if those files have many advanced C++ code.
Clangd is a compiler level parser, so it parse the source file correctly.
@ollydbg
Thanks for the answer. Then, if you know where to find information that will help improve code completion to a modern level, please let me know. Previously, someone wrote a code completion, but now - no one is capable of it?
The problem here is not to write the code, but to understand how it works, you can say the algorithm of actions.
I second the remark by @ollydbg. Modern C++ has gotten extremely complex to parse. Even before C++11 it was complex. Recent standards like C++20 have added a ton of additional complexity and are continuing to do so.
Have you ever met a C++-compiler or -library programmer? It is a humbling experience.
It would be a lot more useful to help solving problems already reported in the bugtracker. Thank you for offering help.
Quote from: Pecan on June 13, 2023, 07:16:00 PM
@ 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.
(https://it.digitalspace.name/pub/cb-clangs.png)
Quote from: DigitalSpaceName on December 28, 2023, 02:25:02 PM
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 ....
Fixed head rev 13422.
Thanks for reporting and the clarification.
You also no longer have to set the launch at 1 char.
Note that clangd does not offer a list of prior defined names or macros. It offers only a pattern of preprocessor statements.
Great job.
It works for preprocesor as expected and maybe more better than expected.
Thank you.
I noticed that this plugin(the latest revision) can have the #include <xxxx> code completion for the header files, this is a really nice feature.
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.
Quote from: Pecan on March 02, 2024, 06:09:38 PM
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.
This is a really nice feature! Good work!!! I will try it soon.
I have problems with this new svn 13484 version, even after a full C::B rebuild. I use wxWidgets 3.2.4 for C::B on a Windows 11 64 bits.
C::B compiles normally. executable launches normally too, but when I try to open a project, I obtain an unhandled exception. I can try to continue, but C::B does not work as it should.
I have a rpt file which indicates problems within wxsmithlib.dll, but strangely no references to clangd plugin, but it's certainly this plugin which causes the problem. I had no such problem with my previous svn 13482.
I'm on windows 11 fully updated. I use gcc, clangd,... form msys2 installation, fully updated too.
If I disable clangd plugin and use standard codecompletion, it works correctly.
May be, it's something wrong on my side, but until now, I have not found the problem.
gd_on
@gd_on
Please copy the newly built clangd_client.dll from the devel folder to the output folder (since the devel version has debugger info) and try again.
The exception should be caught if you'll respond with "stop" to the exception notice and the .rpt file should have a backtrace.
Alternatively, you could run coldeblocks in the debugger and repond "stop" to the exception and the debugger will stop on the exception line.
Make sure that your debugger options are set to "catch c++ exceptions" and that you compiled all of codeblocks with the -g compiler option (Settings/Globals cb_release_type).
Thanks.
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.
Quote from: gd_on on March 04, 2024, 10:26:23 AM
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.
@gd_on
That's interesting. Looks like I'd better do some testing with gnu++20.
Thanks for reporting that.
Please tell me the version of gcc and clangd you're using so I can exactly mirror your evnvironment. Tell me also anything else you think I should mirror?
QuotePlease 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.
I have tried this new plugin which seems quite interesting and much better replacement for code completion plugin but I am struggling to set up everything correctly.
Win11 Codeblocks svn 13485, compiler MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders) 13.1.0
There are several interesting things I will try to describe.
1. run Codeblock through CbLauncher.exe vs. directly codeblocks.exe
note: I am using directly codeblocks.exe through a problem to setup color schemes using CbLauncher
In this case, after enable plugin, the plugin is inactive (using directly codeblocks.exe) with information that CB need to be restarted and compiler set. After restart plugin is inactive and there is no access to setting for plugin.
note: In case using CBLauncher, it does work.
2. LSP messages (using through CBLauncher)
I got really big bunch of errors, it seems that there is no recognition of templates, std namespace, includes headers etc.
Point2.hpp|126|error:Unknown type name 'T'
TestPoint2.hpp|14|error:Use of undeclared identifier 'std'
TestPoint2.hpp|3|error:In included file: 'concepts' file not found
- this is linked to #include <concepts>
This is probably problem with settings but what can be done?
I have installed the 4 files specified in wiki manually in Clangd folder under Codeblocks and set the path in C/C++ parser tab.
@garwin
For my clarity, and some things I don't understand.
Quote
note: I am using directly codeblocks.exe through a problem to setup color schemes using CbLauncher
I don't understand what "problem to setup color schemes" means.
Quote
I have installed the 4 files specified in wiki manually in Clangd folder under Codeblocks and set the path in C/C++ parser tab.
What four files did you install and where did you install them?
Have you disabled CodeCompletion plugin first, then enabled Clangd_Clinet plugin second. from MainMenu/plugins/ManagePlugin. CodeCompletion plugin and Clangd_client plungin cannot run together.
After doing the above enable/disable of plugin, you must then restart CodeBlocks.
Again, very important that CodeCompletion be disabled and Clangd_client be enabled and CodeBlocks restarted. See the image below. CodeCompletion must show as greyed out.
Then, using MainMenu/Settings/Editor/Clangd_client/C++Parser (tab) set the full path location of clangd.exe.
@Pecan
I did it exactly as you describe except last step (see bellow)
I think I was able to dig into the problem, but do not know the solution.
I use codeblock.exe directly which saves settings in Windows in AppData\Roaming.
I did not change these settings after I updated to the last nightly build (previously using the last official version of codeblocks).
But using this old setting means that I can disable this old CodeCompletion plugin and enable Clangd_clinet plugin however cannot setup Clangd_client because I have no options to do so in Settings/Editor. There are all different settings (General setting, Folding ....) but no Clangd. So after restarting codeblocks, Clangd_client is disabled.
(https://i.imgur.com/S2iyqGi.png)
@garwin
Please provide the following information so that I can setup my environment the same as yours and try to detect the error.
Within code tags (the # icon above the reply box) provide the appdata\roaming\codeblocks\ "personality" causing the problem. In the example below the "personality" is "default" at the bottom right of the codeblocks window (yours may be different). It will reside at \users\<your pc users name>\appdata\roaming\codeblocks\<personality name>.conf .
Also provide the codeblocks log (within code tags). The title of the tab is "Code::Blocks". It may look empty, but just use the mouse wheel up or down to see the data.
Right click on the tab title and select copy to clipboard.
Then paste it between code tags so we can analyze it.
Tell me
exactly how to start codeblocks.exe the same way you do to cause the error.
@Pecan
Thank you for helping, I am just hobbiest, so these toolchains and all the settings are difficult to me, but I like simplicity and your plugin would really help compared to code completion plugin which sometimes works, sometimes does not, especially for member functions.
I have just finished an additional try and was able to make Clangd plugin work but with an obscure way and not fully. See below. So now I need:
- to make plugin Clangd working with standard library (point 1 below)
- to find why I need really obscure way to run that plugin (point 2 below)
1. Actual status - The plugin is working but anything from std namespace does not
It seems, that that Clangd is unable to locate library headers. I have added to the compiler search directory:
... Codeblocks\MinGW 13.1\include
... Codeblocks\MinGW 13.1\include\c++
... Codeblocks\MinGW 13.1\include\c++\13.1.0
... Codeblocks\MinGW 13.1\lib\gcc\x86_64-w64-mingw32\13.1.0\include
... Codeblocks\MinGW 13.1\lib\gcc\x86_64-w64-mingw32\13.1.0
... Codeblocks\MinGW 13.1\lib\gcc\x86_64-w64-mingw32
It did not help.
This is from LSP message:
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|
This is basic testing code.
#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!
2. How I did it.
I have not installed MinGW, I have just copy whole MinGW folder under Codeblocks and setup compiler after first opening correctly as it works.
Under Compiler setttings->Selected Compiler I always make copy of default (not setup) GNU GCC Compiler. In this case GNU GCC Compiler 13.1 and setup it correctly and make it default. Run easy code and check that it works.
But if I do that Clangd plugin is always automatically disabled on opening or inactive after enabling it. When I tried to setup original default GNU GCC Compiler in same way, it works and I get to point 1 describe above. This is really strange.
I have included config file in zip, I do not want to spam this forum as it is quite a number of rows.
@ 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?
Quote from: Pecan on March 13, 2024, 08:19:40 PM
@ 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?
Codeblocks find installed compiler as it compiles code without any problem.
MinGW 13.1This version - https://github.com/brechtsanders/winlibs_mingw/releases/download/13.1.0-16.0.5-11.0.0-msvcrt-r5/winlibs-x86_64-posix-seh-gcc-13.1.0-mingw-w64msvcrt-11.0.0-r5.7z
copied to:
Codeblocks\MinGW 13.1
Compiler setup
(https://i.imgur.com/13s4Psg.png)
Debugger setup
(https://i.imgur.com/AwhsXhg.png)
And it compiles correctly code from previous post.
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.exe
msvcp140.dll
vcruntime140.dll
vceruntime140_1.dll
copied to:
Codeblocks\Clangd
which is setup in the plugin.
(https://i.imgur.com/E6JxexC.png)
note: I have even tried to unzip whole LLMV-17.0.6.-win64.exe and set path to this clangd
@ garwin
Are you opening the example program file from a <projectName>.cbp file or as a single c++ file?
@Pecan
From the project cbp file or choosing a project from recent projects on the main codeblocks window.
It seems to me that clangd needs GCC standard library headers but cannot find them. But I have no idea how to tell Clangd where to find them, especially as they are in a lot of folders in MinGW.
I have tried to add to most of these directories in compiler search directories but it does not help.
@Pecan
Find something but I do not know how to solve it. It mark MinGW directories as non-existent but they exist.
Trying run command:
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
Finding this discussion but quite late here, will look tomorrow.
This one - https://github.com/clangd/vscode-clangd/issues/393 (https://github.com/clangd/vscode-clangd/issues/393)
And especially this one - https://clangd.llvm.org/faq#how-do-i-fix-errors-i-get-when-opening-headers-outside-of-my-project-directory (https://clangd.llvm.org/faq#how-do-i-fix-errors-i-get-when-opening-headers-outside-of-my-project-directory) - but how can I do it in codeblocks?
@garwin
Remove the space(s) in"....mingw 13.1/....
In other words, rename "Mingw 13.1" to Mingw13.1 (no space).
Do not use spaces in file or path names.
Bet it'll work after removing the spaces.
Important:
After removing the spaces in the paths,
delete the .cache directory in your project folder.
Delete the compile_commands.json file in your project folder before you load the project again.
This has to be done only once to remove the path names stored with spaces.
The reason why no spaces allowed. Clangd and friends are cross OS tools. And Unix derived tools cannot have spaces in files and paths.
Quote from: Pecan on March 14, 2024, 12:18:41 AM
@garwin
Remove the space(s) in"....mingw 13.1/....
Thanks a lot, that's it and adding everything to the search directory. I usually do not use spaces but for whatever unknown reasons I did it for the compiler version.
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)
Quote from: garwin on March 15, 2024, 09:37:41 PM
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)
Thanks
The URL has been corrected. And thanks for the doxygen info.
I will see what I can do about DDE opened projects not being parsed automatically.
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.
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
Thanks, Christo
Quote from: christo on March 19, 2024, 06:21:49 PM
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.
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
Thanks, Christo
@ christo
Thanks for your work on this.
When there are multiple extraneous #includes in the same file, the patch is taking out the wrong lines after the first one is successful.
So I'll hold onto this until I have time to find out why.
Applied modified christo patch to Clangd_client at Head rev 13493.
The patch supports additional fixes from Clangd version 18.
Thanks christo.
are you planning to introduce other patches by christo as :
https://forums.next.codeblocks.org/index.php/topic,25570.msg174618.html#msg174618 to mark warnings in yellow, errors still in red
and
https://forums.next.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
Quote from: gd_on on March 22, 2024, 06:47:38 PM
are you planning to introduce other patches by christo as :
https://forums.next.codeblocks.org/index.php/topic,25570.msg174618.html#msg174618 to mark warnings in yellow, errors still in red
and
https://forums.next.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
I'll have a look at them. Thanks for the reminder.
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.
Quote from: christo on March 24, 2024, 11:58:39 AM
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?
Quote from: Pecan on March 24, 2024, 05:57:53 PM
Quote from: christo on March 24, 2024, 11:58:39 AM
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?
Hi Pecan,
1. Create a new console application project
2. replace code in main.cpp with below code
int main()
{
std::cout << "Hello";
return 0;
}
3. Clangd (I'm using v18) gives below diagnostic
Quote
/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"
5. Error pop-up is shown instead of applying the fix "No available fixes found"
Yes, I use Clangd 18 and got the same problem, too.
Quote from: Grit Clef on March 25, 2024, 11:56:01 AM
Yes, I use Clangd 18 and got the same problem, too.
Yep, my assumption error. The error is from line 2 but the fix is to line 0, and my code is looking for a fix to line 2.
Wups
Quote from: christo on March 24, 2024, 11:58:39 AM
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. 13494
Thanks for the reports.
Quote from: Pecan on March 26, 2024, 02:01:45 AM
Fixed Head rev. 13494
Thanks for the reports.
It works now, thank you Pecan for the quick response as always.
- "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
Quote from: tomay3000 on April 04, 2024, 03:48:27 PM
- "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?
Quote from: Pecan on April 04, 2024, 06:09:29 PM
Quote from: tomay3000 on April 04, 2024, 03:48:27 PM
- "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.
Quote from: tomay3000 on April 07, 2024, 01:16:05 PM
Quote from: Pecan on April 04, 2024, 06:09:29 PM
Quote from: tomay3000 on April 04, 2024, 03:48:27 PM
- "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.
Quote from: Pecan on April 07, 2024, 06:18:16 PM
Quote from: tomay3000 on April 07, 2024, 01:16:05 PM
Quote from: Pecan on April 04, 2024, 06:09:29 PM
Quote from: tomay3000 on April 04, 2024, 03:48:27 PM
- "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.
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)
Any declaration gives an error.
@ tomay3000
I'll install that compiler and see what's going on.
BTW: what clangd.exe did you setup in Clangd_client and where can I get it to also mirror your environment?
Quote from: kakas on April 09, 2024, 05:28:18 PM
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.
I've moved this message here from personal msgs so that we all can proffer from the solution.
@ kakas
I'd suggest that you uninstall (or remove) that old nightly 16 December 2023 and install this the April 1, 2024 version instead since it has many additions and fixes over last years version.
https://forums.next.codeblocks.org/index.php/topic,25755.msg175319.html#msg175319
You don't actually "install" it. You just download and unzip the three zips into a newly made folders.
cbNightly <-- new main nightly folder
codeblocks <-- contains all the codeblocks zips except the compiler zip.
mngw64 <-- contains the compiler contents
Start a command session click the windows key then type "cmd" and enter key.
From with the cmd window "cd cbNightly\codeblocks
Type: codeblocks.exe /d
Question: Does codeblocks show ok?
If so, Check that the compilers tool chain is set to the download mingw64 executables.
Click mainMenu/Settings/Compiler/Toolchain executables
See second image below.
Please excuse me if I insult your intelligents. I just want to get the basics out of the way so we have approximately the same setup to work with.
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?
:D thank you for the reassuring reply.
about the issue. There's another thing I would like to add.
when enabling the the plugin, A pop up message appears on the bottom right of the screen.
Quote from: Pecan on April 09, 2024, 07:48:48 PM
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) I am not really sure what this means(but I use 64 bit version of everything whenever possible, just cuz of the paranoia that things might not work, I also have built for only 64bit systems)
3) Yes it's same as displayed in the image
(about the nightly build, I haven't tried April 1st built yet.)
Something happened and I lost this post.
So I'm reposting.
Quote from: kakas on April 09, 2024, 05:28:18 PM
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.
I've moved this message here from personal msgs so that we all can proffer from the solution.
@ kakas
I'd suggest that you uninstall (or remove) that old nightly 16 December 2023 and install this the April 1, 2024 version instead since it has many additions and fixes over last years version.
https://forums.next.codeblocks.org/index.php/topic,25755.msg175319.html#msg175319
You don't actually "install" it. You just download and unzip the three zips into a newly made folders.
cbNightly <-- new main nightly folder
codeblocks <-- contains all the codeblocks zips except the compiler zip.
mngw64 <-- contains the compiler contents
Start a command session click the windows key then type "cmd" and enter key.
From with the cmd window "cd cbNightly\codeblocks
Type: codeblocks.exe /d
Question: Does codeblocks show ok?
If so, Check that the compilers tool chain is set to the download mingw64 executables.
Click mainMenu/Settings/Compiler/Toolchain executables
See second image below.
Please excuse me if I insult your intelligents. I just want to get the basics out of the way so we have approximately the same setup to work with.
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?
Quote from: kakas on April 09, 2024, 08:31:19 PM
Quote from: Pecan on April 09, 2024, 07:48:48 PM
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.)
Good , then we're both on the same page.
So now, remove the old December CodeBlocks and download the April one as noted in my last post.
We'll start from there to straighten thing out.
Oh, BTW be sure to close and restart CB after disabling CodeCompletion and re-enabling Clangd_client.
Else all sorts of weirdness happens.
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
Quote from: kakas on April 09, 2024, 09:14:46 PM
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
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.
The Clangd_client is not enabling itself because CB did not find a default compiler. Go to mainMenu/Setting/Compiler/Toolchain executable and set the compiler location as show in the second image below but using
your compiler location of course.
Restart CB and you'll see that Clangd_client is now enabled.
Go to mainMenu/Settings/Editor/Clangd_client/C/C++ parser (the second tab) and put the location of your ...\msys64\mingw64\bin\clangd.exe into the "specify clangd executable to use" search slot. Click ok at bottom.
See the first image below.
Close and restart CB.
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.
Now do us a favor. Open a cmd window and cd to the folder that contains your ...\msys64\mingw64\bin\clangd.exe and type: (without the quotes)
"clangd.exe --version" and tell us what it printed.
Also type: "c++.exe --version" and tell us what it printed.
Regards
Quote from: Pecan on April 10, 2024, 07:26:23 AM
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.
oh I think this is causing the problem. I have no clangd.exe or clang.exe in my mingw64 folder. It's only present in clang64 folder.
Is there another command that I should be running from the msys terminal to download the correct clangd.exe? because I remember running only a single command from the guide.
ran the other command from the guide "pacman -S mingw-w64-x86_64-clang-tools-extra" which downloaded the executables to mingw64 folder instead of clang64.
sorry I got mixed up by the commands in the guide at first (attached screenshot of command prompt showing version details of clangd.exe and c++.exe)
Went through the enabling plugin procedure again to see if it fixed the issue. But no pogress.
Despite the "To run Clangd_Client, restart CodeBlocks after setting up a compiler...." error,
Code blocks seems to compile files just fine. Compiler installation directory(contains clangd.exe and clang.exe) C:\msys64\mingw64.
So I am not sure if the problem comes from CB not finding a default compiler.
Quote from: Pecan on April 10, 2024, 07:26:23 AM
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"
SOLVEDDD
I had to set the default compiler to *No-compiler*
before enabling or disabling any plugin.
this time(having no-compiler as default) it didn't gave the error pop-up on the bottom right when enabling the Clangd_Client plugin, but said CB needs to restart for the plugin to function properly.
After setting up the clangd.exe path in the editor settings and restarting again, the plugin works. And it's awesome ;D ;D ;D
Quote from: kakas on April 10, 2024, 09:40:46 AM
Quote from: Pecan on April 10, 2024, 07:26:23 AM
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"
Actually, there is a URL on the Nightly announcement that can be used to download the compiler that was used to make the Nightly CodeBlocks.
But you've solved your setup problems already.
Thanks for your patience and your persistence.
This has informed me on what can go awry and how to improve the instructions on setting up Clangd_client.
You might want to go through the list of plugins (mainmenu/plugins/manage plugins) and disable or uninstall the plugins that you do not use. It'll unclutter your logs section.
If you haven't found it yet, the "LSP messages" tab in the log section is the one that contains the output from Clangd/Clangd_client and may have suggestions on how to correct syntax or symbol references.
If you see a message that contains "(fix available)" you can right-mouseClick on the message and apply the fix automatically if you agree with the suggested fix.
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.
But you might have to update to mingw64/clangd.exe version 18 (when it becomes available in msys64) before you can take full advantage of this.
Regards
I should be the one thanking you for this amazing plugin ;D
Quote from: Pecan on April 10, 2024, 05:43:01 PM
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
Quote from: MaxGaspa on April 16, 2024, 12:02:56 PM
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
Quote from: Pecan on April 16, 2024, 06:37:58 PM
Would you please give steps to re-create and trace the problem, i.e.,
1) do this
2) now do that
1) open a project with multiple source file, so the whole parsing process takes time (more than few seconds)
2) During the parsing process open a source file
3) Select in the box (shown in the attached e-mail) a choice
4) When the parsing of a file is completed the box is cleared (made empty).
In case I can make a video....
Max
Video linked from my google drive
https://drive.google.com/file/d/1AkwcYDVfGzkcidiqIOcD7T3ZZU4wHxom/view?usp=drive_link
Hope this helps
Max
Quote from: MaxGaspa on April 16, 2024, 12:02:56 PM
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
Thanks for the video. It cleared up (in my head) what box you were trying to point out.
That box is called the Clangd_client (or CodeCompletion) toolbar.
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.
The left hand side (the one you were clicking in) displays the classes in an active editor file, and the right hand choice box shows all functions within the class.
You can cause the editor to position on a class/function by clicking in the left hand choice box to choose the class, then click in the right choice box and choosing what function to position to.
What's happening in your video is that you never activated the editor by clicking into it. So the choice boxes were never populated.
Regards
Quote from: Pecan on April 17, 2024, 07:09:19 PM
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
Quote from: MaxGaspa on April 17, 2024, 11:28:29 PM
Quote from: Pecan on April 17, 2024, 07:09:19 PM
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
I cannot reproduce this. So would you start CB with the -d or /d parameter so that the Code::Blocks Debug log is produced.
Before you load your project be sure that the "CodeBlocks Debut" log tab is focused.
Do as you have done to cause the bug, then right-click the Code::Blocks Debug tab and choose copy "contents to clipboard", Paste it into a message here between code tags (the # icon above a forum reply box).
Thanks for your patience with this.
It's really peculiar.
BTW: after the new file is parsed and clicked into, can you even perform a Mainmenu/Search/goto function, (Ctrl-Shift-G for me.)
It tells me if if the bug is in the plugin interface to the editor code or the toobar code.
Quote from: MaxGaspa on April 17, 2024, 11:28:29 PM
Quote from: Pecan on April 17, 2024, 07:09:19 PM
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
I just watched the video again.
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.
Tell me if you still get the bug.
If you get the bug, send me the Code::Blocks Debug log as specified in the previous messgage.
Thanks
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.
Quote from: kakas on April 18, 2024, 08:17:02 AM
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.
Quote from: Pecan on April 18, 2024, 06:21:12 PM
Quote from: kakas on April 18, 2024, 08:17:02 AM
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.
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.
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.
Quote from: Pecan on April 18, 2024, 01:18:54 AM
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.
Yes, clicking inside a function or class works. Thanks
Quote from: Pecan on April 18, 2024, 06:21:12 PM
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.
(sorry for the late reply, I lost track of time)
I had to change the file extension since the anything other than image and txt file isn't accepted. Miniaudio.txt is cbp and main.txt is main.c
Quote from: Pecan on April 18, 2024, 11:16:15 PM
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.
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.
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?
Quote from: kakas on April 20, 2024, 08:51:21 PM
Quote from: Pecan on April 18, 2024, 11:16:15 PM
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.
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.
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?
Quote from: kakas on April 20, 2024, 09:02:48 PM
Quote from: kakas on April 20, 2024, 08:51:21 PM
Quote from: Pecan on April 18, 2024, 11:16:15 PM
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.
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.
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?
Yes, breaking up that huge header into multiple headers should do the trick.
Quote from: garwin on March 15, 2024, 09:37:41 PM
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)
Re: Fixed Clangd and parser not parsing when user cold starts CB via DDE. Commit rev 13515
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
Quote from: blauzahn on May 03, 2024, 06:47:11 AM
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
Thanks, corrected (I think) Head r13517.
Please test, because I have no access to Arch linux.
Thank you.
I just compiled it on ubuntu linux without any compile-error. Arch I can do only in the evening. Since the configure args are the same and both use wxWidgets trunk, chances are, that the outcome will be the same on arch.
Head svn13517 compiles again without compile-error on arch linux as well.
When debugging, the current PC (program counter) marker is covered by the clangd_client marker.
See the image below, the first image is that the debugger hits the breakpoint at the line 2342, you see the current PC marker can't be seen
In the second image, you see that if the "next line" button get clicked, the current PC marker can be seen again.
I'd favour hiding the clangd_client marker during debugging. I prefer them sharing the same space like they do now over wasting more real estate on the screen -- even on larger desktop screens.
Quotesvn13517: - Clangd_client include "sdk.h" needed for lspdiagresultslog.cpp no matter what clangd says
FYI: The warning can be suppressed by issueing a pragma:
#include <cmath> // IWYU pragma: keepThat reduces clutter in the clangd_client's LSP messages box in Code::Blocks. OTOH, in general, it makes sense to go the extra mile and remove unneded #include pretty much wherever you can.
In cases like these, cmath is needed to provide M_PI which clangd does not see.
Quote from: ollydbg on May 12, 2024, 03:47:22 PM
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.
Quote from: Pecan on May 13, 2024, 08:57:11 PM
Quote from: ollydbg on May 12, 2024, 03:47:22 PM
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?
@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.
Quote from: blauzahn on May 14, 2024, 07:09:21 AM
@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.
Maybe a combination marker for the "breakpoint" and "clangd_client". ;)
Quote from: ollydbg on May 14, 2024, 02:40:07 AM
Quote from: Pecan on May 13, 2024, 08:57:11 PM
Quote from: ollydbg on May 12, 2024, 03:47:22 PM
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?
I can change it to a small right pointing arrow that fits inside any other marker, or I can code an option to turn off all clangd_client marker.
Which is preferred ?
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?
Quote from: blauzahn on May 14, 2024, 09:26:51 PM
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 use C::B for my daily work, and some of the clangd_client warnings come from third part library's source code, so those warnings will last for a long time.
Thanks.
Quote from: ollydbg on May 15, 2024, 12:03:28 AM
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.
Quote from: Pecan on May 15, 2024, 06:10:46 PM
Quote from: ollydbg on May 15, 2024, 12:03:28 AM
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.
Hi, thanks.
I just tried this latest revision.
There is still one issue, clangd error and breakpoint happens in the same line. Still they have the same size. One is circle, and the other is a square.
I can't reproduce a clangd warning easily. :(
see below image shot:
Quote from: ollydbg on May 16, 2024, 02:45:26 PM
Hi, thanks.
I just tried this latest revision.
There is still one issue, clangd error and breakpoint happens in the same line. Still they have the same size. One is circle, and the other is a square.
I can't reproduce a clangd warning easily. :(
see below image shot:
Same with legacy CC . It's always been that way.
I'd have to change legacy CC use of cbEditor to do anything about that.
I'd prefer not changing legacy CC if I can avoid it.
For me, an obvious code error (red square) should be corrected before debugging occurs. When the error is corrected, the debugger breakpoint circle appears.
Also you can always use the "Debugging windows" icon (top line main menu, left of info icon) to see your breakpoints listed.
I really do not know how to solves this situation without changing the legacy CC interface (cbeditor) for current users.
Legacy CC is used way more than clangd_client.
Suggestions accepted.
QuoteI really do not know how to solves this situation without changing the legacy CC interface (cbeditor) for current users.
Legacy CC is used way more than clangd_client.
Hi, pecan, thanks for the work.
I see it is hard to solve this issue. If I remember correctly, the legecy code completion plugin does not use any markers. So, the issue is that the sdk(cb editor) need to supply more options for the markers.
Hi Pecan,
compile_commands.json is read and parsed every time a file is opened. This uses a lot of CPU, especially during the initial parsing of all files, where
compile_commands.json is read and parsed as many times as the number of files in the project. Attached patch does some optimisation for this.
1. Save the parsed compile_commands.json until the first batch parsing is completed, cleared after that.
2. After initial batch processing, all the filesnames are stored in a vector, and only if the filename is not present in this vector, compile commands is parsed. This helps to avoid parsing of the compile_commands.json after editing and saving of the file.
Thanks, Christo
I see you have made several contribution to C::B. Either in this thread or in the compiler log parsing acceleration (High CPU usage during build operation when verbose is enabled (https://forums.next.codeblocks.org/index.php/topic,25788.0.html))
Great job. But it is a bit hard for me to understand the patch's logic currently.
BTW: Can you show the CPU usage reduction before/after applying this patch? Thanks.
Quote from: christo on June 22, 2024, 11:41:29 AM
Hi Pecan,
compile_commands.json is read and parsed every time a file is opened. This uses a lot of CPU, especially during the initial parsing of all files, where
compile_commands.json is read and parsed as many times as the number of files in the project. Attached patch does some optimisation for this.
1. Save the parsed compile_commands.json until the first batch parsing is completed, cleared after that.
2. After initial batch processing, all the filesnames are stored in a vector, and only if the filename is not present in this vector, compile commands is parsed. This helps to avoid parsing of the compile_commands.json after editing and saving of the file.
Thanks, Christo
Thanks, I'll have a look and do some testing.
Quote from: ollydbg on June 23, 2024, 04:05:12 AM
BTW: Can you show the CPU usage reduction before/after applying this patch? Thanks.
@ollydbg Attaching perf output without and with the optimisation. perf is captured until full codeblocks project is parsed.
Hi Pecan,
Today I use GCC 14.1 with wx 3.2.5 to build CB, but I suddenly got some errors when building Clangd_client.
J:\123\CodeBlocksNightlySrc\codeblocks_sfmirror\src\plugins\contrib\clangd_client\src\codecompletion\parser\parser.cpp||In member function 'bool Parser::LSP_GetSymbolsByType(json*, std::set<LSP_SymbolKind>&, std::vector<std::tuple<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, LSP_SymbolKind, int> >&)':|
J:\123\CodeBlocksNightlySrc\codeblocks_sfmirror\src\plugins\contrib\clangd_client\src\codecompletion\parser\parser.cpp|3667|error: invalid user-defined conversion from 'wxString' to 'char' [-fpermissive]|
J:\123\wxWidgets-3.2.5-cb\include\wx\string.h|1635|note: candidate is: 'wxString::operator const wchar_t*() const' (near match)|
J:\123\wxWidgets-3.2.5-cb\include\wx\string.h|1635|note: no known conversion from 'const wchar_t*' to 'char'|
W:\SoftwareDevelopmentTools\mingw32\include\c++\14.1.0\bits\basic_string.h|840|note: initializing argument 1 of 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(_CharT) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'|
J:\123\CodeBlocksNightlySrc\codeblocks_sfmirror\src\plugins\contrib\clangd_client\src\codecompletion\parser\parser.cpp||In member function 'void Parser::WalkDocumentSymbols(json&, wxString&, int&, std::set<LSP_SymbolKind>&, std::vector<std::tuple<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, LSP_SymbolKind, int> >&)':|
J:\123\CodeBlocksNightlySrc\codeblocks_sfmirror\src\plugins\contrib\clangd_client\src\codecompletion\parser\parser.cpp|3879|error: invalid user-defined conversion from 'wxString' to 'char' [-fpermissive]|
J:\123\wxWidgets-3.2.5-cb\include\wx\string.h|1635|note: candidate is: 'wxString::operator const wchar_t*() const' (near match)|
J:\123\wxWidgets-3.2.5-cb\include\wx\string.h|1635|note: no known conversion from 'const wchar_t*' to 'char'|
W:\SoftwareDevelopmentTools\mingw32\include\c++\14.1.0\bits\basic_string.h|840|note: initializing argument 1 of 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(_CharT) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'|
How to fix this? Thanks.
Edit: I just changed the 'name' in line 3667 and 3879 in parser.cpp to 'name.c_str()', and errors disappeared.
I find that there are several other errors about the same; I remember that I did some changes in wx/msw/setup.h, maybe they influenced the compatibility of wxString and std::string.
Quote from: Grit Clef on June 24, 2024, 07:18:25 AM
Hi Pecan,
Today I use GCC 14.1 with wx 3.2.5 to build CB, but I suddenly got some errors when building Clangd_client.
J:\123\CodeBlocksNightlySrc\codeblocks_sfmirror\src\plugins\contrib\clangd_client\src\codecompletion\parser\parser.cpp||In member function 'bool Parser::LSP_GetSymbolsByType(json*, std::set<LSP_SymbolKind>&, std::vector<std::tuple<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, LSP_SymbolKind, int> >&)':|
J:\123\CodeBlocksNightlySrc\codeblocks_sfmirror\src\plugins\contrib\clangd_client\src\codecompletion\parser\parser.cpp|3667|error: invalid user-defined conversion from 'wxString' to 'char' [-fpermissive]|
J:\123\wxWidgets-3.2.5-cb\include\wx\string.h|1635|note: candidate is: 'wxString::operator const wchar_t*() const' (near match)|
J:\123\wxWidgets-3.2.5-cb\include\wx\string.h|1635|note: no known conversion from 'const wchar_t*' to 'char'|
W:\SoftwareDevelopmentTools\mingw32\include\c++\14.1.0\bits\basic_string.h|840|note: initializing argument 1 of 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(_CharT) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'|
J:\123\CodeBlocksNightlySrc\codeblocks_sfmirror\src\plugins\contrib\clangd_client\src\codecompletion\parser\parser.cpp||In member function 'void Parser::WalkDocumentSymbols(json&, wxString&, int&, std::set<LSP_SymbolKind>&, std::vector<std::tuple<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, LSP_SymbolKind, int> >&)':|
J:\123\CodeBlocksNightlySrc\codeblocks_sfmirror\src\plugins\contrib\clangd_client\src\codecompletion\parser\parser.cpp|3879|error: invalid user-defined conversion from 'wxString' to 'char' [-fpermissive]|
J:\123\wxWidgets-3.2.5-cb\include\wx\string.h|1635|note: candidate is: 'wxString::operator const wchar_t*() const' (near match)|
J:\123\wxWidgets-3.2.5-cb\include\wx\string.h|1635|note: no known conversion from 'const wchar_t*' to 'char'|
W:\SoftwareDevelopmentTools\mingw32\include\c++\14.1.0\bits\basic_string.h|840|note: initializing argument 1 of 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(_CharT) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'|
How to fix this? Thanks.
Edit: I just changed the 'name' in line 3667 and 3879 in parser.cpp to 'name.c_str()', and errors disappeared.
I find that there are several other errors about the same; I remember that I did some changes in wx/msw/setup.h, maybe they influenced the compatibility of wxString and std::string.
I am also using mingw 14.1.0. with wxWidgets 3.2.5 (no modifications), but cannot reproduce this error.
Can you give us steps to reproduce the error?
I believe the Nightly is using the same without errors.
Do you get the error using the nightly build?
Quote from: Pecan on June 25, 2024, 06:55:35 AM
Quote from: Grit Clef on June 24, 2024, 07:18:25 AM
Hi Pecan,
Today I use GCC 14.1 with wx 3.2.5 to build CB, but I suddenly got some errors when building Clangd_client.
J:\123\CodeBlocksNightlySrc\codeblocks_sfmirror\src\plugins\contrib\clangd_client\src\codecompletion\parser\parser.cpp||In member function 'bool Parser::LSP_GetSymbolsByType(json*, std::set<LSP_SymbolKind>&, std::vector<std::tuple<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, LSP_SymbolKind, int> >&)':|
J:\123\CodeBlocksNightlySrc\codeblocks_sfmirror\src\plugins\contrib\clangd_client\src\codecompletion\parser\parser.cpp|3667|error: invalid user-defined conversion from 'wxString' to 'char' [-fpermissive]|
J:\123\wxWidgets-3.2.5-cb\include\wx\string.h|1635|note: candidate is: 'wxString::operator const wchar_t*() const' (near match)|
J:\123\wxWidgets-3.2.5-cb\include\wx\string.h|1635|note: no known conversion from 'const wchar_t*' to 'char'|
W:\SoftwareDevelopmentTools\mingw32\include\c++\14.1.0\bits\basic_string.h|840|note: initializing argument 1 of 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(_CharT) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'|
J:\123\CodeBlocksNightlySrc\codeblocks_sfmirror\src\plugins\contrib\clangd_client\src\codecompletion\parser\parser.cpp||In member function 'void Parser::WalkDocumentSymbols(json&, wxString&, int&, std::set<LSP_SymbolKind>&, std::vector<std::tuple<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, LSP_SymbolKind, int> >&)':|
J:\123\CodeBlocksNightlySrc\codeblocks_sfmirror\src\plugins\contrib\clangd_client\src\codecompletion\parser\parser.cpp|3879|error: invalid user-defined conversion from 'wxString' to 'char' [-fpermissive]|
J:\123\wxWidgets-3.2.5-cb\include\wx\string.h|1635|note: candidate is: 'wxString::operator const wchar_t*() const' (near match)|
J:\123\wxWidgets-3.2.5-cb\include\wx\string.h|1635|note: no known conversion from 'const wchar_t*' to 'char'|
W:\SoftwareDevelopmentTools\mingw32\include\c++\14.1.0\bits\basic_string.h|840|note: initializing argument 1 of 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(_CharT) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]'|
How to fix this? Thanks.
Edit: I just changed the 'name' in line 3667 and 3879 in parser.cpp to 'name.c_str()', and errors disappeared.
I find that there are several other errors about the same; I remember that I did some changes in wx/msw/setup.h, maybe they influenced the compatibility of wxString and std::string.
I am also using mingw 14.1.0. with wxWidgets 3.2.5 (no modifications), but cannot reproduce this error.
Can you give us steps to reproduce the error?
I believe the Nightly is using the same without errors.
Do you get the error using the nightly build?
I would check wxUSE_STL, wxUSE_STD_CONTAINERS_COMPATIBLY, and wxUSE_STD_CONTAINERS values.
And, of course wxUSE_UNICODE should be 1 unless you wish to have a nightmare trying to have it set to 0 and fixing all the problems.
Tim S.
Quote from: stahta01 on June 25, 2024, 11:46:48 AM
I would check wxUSE_STL, wxUSE_STD_CONTAINERS_COMPATIBLY, and wxUSE_STD_CONTAINERS values.
The error message looks like a string conversion error, none of these options affect string conversion.
Quote from: stahta01 on June 25, 2024, 11:46:48 AM
And, of course wxUSE_UNICODE should be 1
I don't think it is possible to build a current wxWidgets without that, i think i saw that some setup headers forcefully set this define to 1 even if u manually set it to 0.
Either compatibility with previous wxWidgets versions has been disabled or more likely
wxUSE_UNSAFE_WXSTRING_CONV was disabled. If it was the latter, it would be a good idea to update the code, because using this automatic conversion can lead to fancy errors.
Oh yes, as sodev said, I just disabled wxUSE_UNSAFE_WXSTRING_CONV. Those STL containers related options have been modified, too, but I don't think they really influence the conversion from wxString to std::string.
Quote from: Grit Clef on June 26, 2024, 04:41:00 AM
Oh yes, as sodev said, I just disabled wxUSE_UNSAFE_WXSTRING_CONV. Those STL containers related options have been modified, too, but I don't think they really influence the conversion from wxString to std::string.
Since, IIRC, using STL means wxString is stored as std::string I would say you are technically right but, if the other person is using an STL built wxWidgets and you are not then you could have that as the cause of your problem!
Tim S.
Quote from: christo on June 22, 2024, 11:41:29 AM
Hi Pecan,
compile_commands.json is read and parsed every time a file is opened. This uses a lot of CPU, especially during the initial parsing of all files, where
compile_commands.json is read and parsed as many times as the number of files in the project. Attached patch does some optimisation for this.
1. Save the parsed compile_commands.json until the first batch parsing is completed, cleared after that.
2. After initial batch processing, all the filesnames are stored in a vector, and only if the filename is not present in this vector, compile commands is parsed. This helps to avoid parsing of the compile_commands.json after editing and saving of the file.
Thanks, Christo
Here some results from this christo patch.
The first millisecond measure following the filename is the parse time prior to the patch; the second is after applying the patch. There's a significant savings there. And it has a visible effect. It even
feels faster.
Looks like I'll be applying the patch.
Thanks Christo.
parser_base.cpp (1601 ms) (1264 ms)
codecompletion.cpp (2281 ms) (1776 ms)
LSP_tokenizer.cpp (1806 ms) (1235 ms)
parser.cpp (2462 ms) (1455 ms)
LSP_symbolsparser.cpp (2322 ms) (1706 ms)
coderefactoring.cpp (1744 ms) (1277 ms)
parsemanager.cpp (2274 ms) (1601 ms)
classbrowser.cpp (1723 ms) (1305 ms)
lspdiagresultslog.cpp (1253 ms) (524 ms)
ccoptionsdlg.cpp (1975 ms) (1554 ms)
ClangLocator.cpp (1295 ms) (1125 ms)
client.cpp (2417 ms) (1764 ms)
searchtree.cpp (596 ms) (329 ms)
cctreectrl.cpp (1983 ms) (1218 ms)
expression.cpp (2114 ms) (1238 ms)
token.cpp (1005 ms) (444 ms)
profiletimer.cpp (1983 ms) (251 ms)
ccdebuginfo.cpp (3174 ms) (1227 ms)
tokentree.cpp (2094 ms) (347 ms)
ccoptionsprjdlg.cpp (2878 ms) (1147 ms)
parsemanager_base.cpp (2345 ms) (410 ms)
selectincludefile.cpp (1791 ms) (395 ms)
doxygen_parser.cpp (3337 ms) (1299 ms)
StringUtils.cpp (491 ms) (346 ms)
gotofunctiondlg.cpp (1834 ms) (964 ms)
processreaderthread.cpp (1546 ms) (855 ms)
insertclassmethoddlg.cpp (2344 ms) (1155 ms)
procutils.cpp (1107 ms) (1078 ms)
winprocess_impl.cpp (1186 ms) (1076 ms)
winprocess.cpp (872 ms) (822 ms)
fileutils.cpp (1167 ms) (1219 ms)
asyncprocess.cpp (1755 ms) (1281 ms)
Hello Developers.
In his Reply #88 on: February 11, 2022, 03:26:20 am ollydbg mentioned
Quote
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. :)
I faced the same issue. But I'm using the build-suite under in the folder "msys64\
ucrt64\bin" and thus, I had to install package
mingw-w64-ucrt-x86_64-clang-tools-extra for adding the clangd tool to my compiler-suite.
Maybe it is a good idea to add this in your wiki-page https://wiki.codeblocks.org/index.php/CB_Clangd_Client (https://wiki.codeblocks.org/index.php/CB_Clangd_Client) in the chapter
Windows: Compiler Clangd/LLVM Package InstallerBest regards,
Eckard Klotz.
Quote from: eckard_klotz on September 28, 2024, 02:50:14 PM
Hello Developers.
In his Reply #88 on: February 11, 2022, 03:26:20 am ollydbg mentioned
Quote
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. :)
I faced the same issue. But I'm using the build-suite under in the folder "msys64\ucrt64\bin" and thus, I had to install package mingw-w64-ucrt-x86_64-clang-tools-extra for adding the clangd tool to my compiler-suite.
Maybe it is a good idea to add this in your wiki-page https://wiki.codeblocks.org/index.php/CB_Clangd_Client (https://wiki.codeblocks.org/index.php/CB_Clangd_Client) in the chapter Windows: Compiler Clangd/LLVM Package Installer
Best regards,
Eckard Klotz.
Hi, I think you can edit the wiki by yourself if you have a codeblocks forum account.
Can you try that? Thanks.
Hello Ollydbg.
QuoteHi, I think you can edit the wiki by yourself if you have a codeblocks forum account.
Can you try that? Thanks.
OK, I tried and it was possible for me.
However, since I changed a document initially setup by somebody else, I would never do such a change without discussing it before.
Furthermore, it is important for me that somebody takes a look to it and if possible tries out if my extension describes really the correct procedure.
So it would be nice if somebody else will test it and will come back a comment if it works or not.
Best regards,
Eckard Klotz.
Quote from: eckard_klotz on September 29, 2024, 09:26:55 AM
Hello Ollydbg.
QuoteHi, I think you can edit the wiki by yourself if you have a codeblocks forum account.
Can you try that? Thanks.
OK, I tried and it was possible for me.
However, since I changed a document initially setup by somebody else, I would never do such a change without discussing it before.
Furthermore, it is important for me that somebody takes a look to it and if possible tries out if my extension describes really the correct procedure.
So it would be nice if somebody else will test it and will come back a comment if it works or not.
Best regards,
Eckard Klotz.
I understand your concern, and a wiki page is a shared resource, and I'm OK if you add any contribution to that page, especially this section:
7 Windows: Compiler Clangd/LLVM Package Installer (https://wiki.codeblocks.org/index.php/CB_Clangd_Client#Windows:_Compiler_Clangd.2FLLVM_Package_Installer)
Thanks.
Quote from: wtfisgoingoff on October 11, 2024, 04:15:32 PM
When using code completion plugin , after whi typed, a popup window showed with content C++ while , and I can just press enter, while will be printed in editor. It works for those keywords too [for switch ...]But when using Clangd_Client plugin, after whi typed ,nothing happen. I have to type the whole word by myself. Same happened to [for switch ...]
Does Clangd_Client plugin supports this feature? Thx
(https://img.erpweb.eu.org/imgs/2024/10/d0b374b31d7bd50b.png)
(https://img.erpweb.eu.org/imgs/2024/10/d8c204c2efc686ee.png)
I've noticed this also. Clangd does not respond to keywords. But you can easily add them to your abbreviations set. Settings/Editor/Abbreviations.