Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on May 28, 2022, 09:38:39 am

Title: The 28 May2022 build (12818) is out.
Post by: killerbot on May 28, 2022, 09:38:39 am
We switched to wx 3.1.5 --> download the new wx dll's see link below

If you tested the 22 january nightly you may find your compiler executable has changed from gcc.exe to mingw32-gcc.exe and g++.exe to mingw32-g++.exe. Please correct this, you won't be asked again.

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works (http://forums.codeblocks.org/index.php/topic,3232.0.html).

A link to the unicode windows wxWidget dll(s) for Code::Blocks : https://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw31u_gcc_cb_wx315_2D_gcc810-mingw64.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls8.1.0.7z


The 28 May 2022 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2022/CB_20220528_rev12818_win64.7z
  - Linux :
   none

The current SDK version is : 2.18.0

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 28 May2022 build (12818) is out.
Post by: rechtsanwaltsteyer on May 28, 2022, 10:45:01 am
Good day to anyone.
Why are there no nightly builds for Linux???
Tnx for an answer!
Title: Re: The 28 May2022 build (12818) is out.
Post by: AndrewCot on May 28, 2022, 10:59:40 am
If you are desperate then build C::B yourself from source.

I would suggest reading the previous nightly post threads and read them to see how nighty releases are done.

Title: Re: The 28 May2022 build (12818) is out.
Post by: Xaviou on May 28, 2022, 11:43:43 am
Hi.

OS X version of this rev can be downloaded from my Google Drive (https://drive.google.com/drive/folders/1-r9cbW1I8ZkaCt6iYDhcXH981n5FJTpV?usp=sharing).
There is a specific dmg file for versions 10.15 and 11.6 of the OS.
Note that these are not notarized versions of the application.

32 bits version for Windows can also be found in the same place.

Debian Buster and Bullseye (32 and 64 bits) can be installed from my repo (https://wxstuff.xaviou.fr/article/debian-repository.html).

Regards
Xav'
Title: Re: The 28 May2022 build (12818) is out.
Post by: Pecan on May 28, 2022, 11:03:53 pm
The Clangd_Client for this nightly can be downloaded at
https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/

Filename: ClangdClientForCBNightly_20220528_rev12818_win64.zip (Direct download link (https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/ClangdClientForCBNightly_20220528_rev12818_win64.zip/download))

Copy the included clangd_client.zip to  <YourCodeBlocksNightlyFolder>\share\CodeBlocks\clangd_client.zip
Do not unzip this file.

Copy the included clangd_client.dll to <YourCodeBlocksNightlyFolder>\share\CodeBlocks\plugins\clangd_client.dll

Restart your CodeBlocks Nightly.

Install instructions for LLVM/clangd are included within the downloaded .zip file.
Modify message
Title: Re: The 28 May2022 build (12818) is out.
Post by: 20k on May 30, 2022, 10:21:20 pm
Hello! I thought I'd give the clangd code completion a go, its amazing to see it finally starting to work its way into codeblocks. It seems to largely work, except for some reason in the floating box suggestion window, it always shows GImGuiFreeTypeAllocatorUserData for the type (Edit: This seems to be a race condition, it'll pick one type and then stick with it - from different files at random)

https://i.imgur.com/hRwqxxk.png

Its definitely a little slower than the old parser, but the old parser was very much starting to struggle with modern C++ concepts (and to some degree, trying to parse modern C++ correctly is a losing battle anyway), so working fully clang autocomplete would be a definite upgrade

I also encountered a bug when upgrading from a previous nightly (12516), previously I'd set up my own msys2 compiler, and this seemed to cause the compiler plugin to crash because of duplicate compiler IDs. Setting up the msys mingw64 built in compiler and saving everything then restarting seemed to fix it. Thought I'd put that here in case anyone else runs into the same issue

Thanks!

Edit 2:

Pressing enter on a file which the code completion has been requested to treat as a source file (in this case, a .cl file) pops up an error repeatedly saying that it hasn't been parsed yet. This is just for inserting a newline
Title: Re: The 28 May2022 build (12818) is out.
Post by: Pecan on May 31, 2022, 06:08:32 pm
Quote from: 20k on May 30, 2022, 10:21:20 pm
Hello! I thought I'd give the clangd code completion a go, its amazing to see it finally starting to work its way into codeblocks. It seems to largely work, except for some reason in the floating box suggestion window, it always shows GImGuiFreeTypeAllocatorUserData for the type (Edit: This seems to be a race condition, it'll pick one type and then stick with it - from different files at random)

https://i.imgur.com/hRwqxxk.png
Can you give me the exact steps to try and recreate this bug?

Quote from: 20k on May 30, 2022, 10:21:20 pm
Pressing enter on a file which the code completion has been requested to treat as a source file (in this case, a .cl file) pops up an error repeatedly saying that it hasn't been parsed yet. This is just for inserting a newline

What is a .cl file (I found about a dozen definitions) and what do you mean by "code completion has been requested to teat as a source file" ?
How do I recreate this situation?
Title: Re: The 28 May2022 build (12818) is out.
Post by: 20k on June 01, 2022, 04:56:58 am
Quote from: Pecan on May 31, 2022, 06:08:32 pm

What is a .cl file (I found about a dozen definitions) and what do you mean by "code completion has been requested to teat as a source file" ?
How do I recreate this situation?


For the latter bug

1. Under settings -> editor -> clangd_client -> C/C++ parser (adv.), add ,cl to "file extensions to parse as source files". This is an OpenCL source file, but this bug repros without this being important

2. Make a new project (in my case, file new project, console application, C++, named test)

3. file -> new file -> empty file -> call it test.cl and create it in the current directory. I added it to debug and release

4. Navigate to new file, click, and hit enter to insert a newline. "Editors file is not yet parsed." pops up every time enter is pressed

My codeblocks config should be relatively standard other than that, but if this doesn't work I'll try and provide more detailed information. Clangd is set to C:\msys64\mingw64\bin\clangd.exe, and this is the clangd provided by msys2's mingw-w64-x86_64-clang-tools-extra package for the mingw64 distribution

Quote from: Pecan on May 31, 2022, 06:08:32 pm

Can you give me the exact steps to try and recreate this bug?


This is for a big project so less straightforward. So, with step 1 from the above bug report also applied (ie adding .cl files to the list of extensions)

1. Check out the repo https://github.com/20k/numerical_sim recursively with submodules, on the branch 'codeblocksrepro'. I use tortoisegit so I don't have a cli command here for you, but there its just right click git clone -> URL: git@github.com:20k/numerical_sim.git and tick recursive, with the branch set to codeblocksrepro

2. Open it up in codeblocks via clicking numerical_sim.cbp

3. Under sources, navigate to mesh_manager.cpp

4. Line 67 reads buf.matter_term = std::get<5>(values[kk]);

5. Make a newline after line 67, and type "buf."

6. It then displays a message (incorrectly) referring to cpu_mesh, and the init function https://i.imgur.com/blm3jww.png

7. Delete your addition, and restart codeblocks, repeating steps 2-6

8. Get a different message https://i.imgur.com/ngeHlmM.png

This project hasn't been tweaked at all to parse better under clang - so parse errors don't surprise me particularly, but the non determinism seems like there's a race condition happening somewhere. The list of members is correct indicating that its at least mostly correctly parsed, it just the extracted type that's incorrect

Scrolling through the different members of .buf in the popup does not change the message that's displayed, and between this and the non determinism it makes me suspect a bug in the code completion itself rather than a simple parse failure

I just checked the LSP diagnostics for mesh_manager.cpp and that doesn't output any errors, just uninteresting C++ stylistic warnings, so that file at least seems to be parsing mostly correctly

The code completion is set to use only 1 thread, and I tested messing with this number to see if it affects the result. It does not. All the testing I did just now is with the concurrently parsing thread count set to 1

Thanks!