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
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.png7. Delete your addition, and restart codeblocks, repeating steps 2-6
8. Get a different message
https://i.imgur.com/ngeHlmM.pngThis 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!
