2026-02-20 11:31 AM - edited 2026-02-20 11:32 AM
.clangd is constantly being modified appending the same compileflags:
CompileFlags:
Add:
- '-ferror-limit=0'
- '-Wno-implicit-int'
CompilationDatabase: CM7/build
Diagnostics:
Suppress:
- unused-includes
- unknown_typename
- unknown_typename_suggest
- typename_requires_specqual
If:
PathMatch: CM7/.*
---
CompileFlags:
Add:
- '-ferror-limit=0'
- '-Wno-implicit-int'
CompilationDatabase: CM4/build
Diagnostics:
Suppress:
- unused-includes
- unknown_typename
- unknown_typename_suggest
- typename_requires_specqual
If:
PathMatch: CM4/.*
---
CompileFlags:
Add:
- '-ferror-limit=0'
- '-Wno-implicit-int'
CompilationDatabase: CM4/build
Diagnostics:
Suppress:
- unused-includes
- unknown_typename
- unknown_typename_suggest
- typename_requires_specqual
If:
PathMatch: CM4/.*
---
CompileFlags:
Add:
- '-ferror-limit=0'
- '-Wno-implicit-int'
CompilationDatabase: CM7/build
Diagnostics:
Suppress:
- unused-includes
- unknown_typename
- unknown_typename_suggest
- typename_requires_specqual
If:
PathMatch: CM7/.*
---
CompileFlags:
Add:
- '-ferror-limit=0'
- '-Wno-implicit-int'
CompilationDatabase: CM7/build
Diagnostics:
Suppress:
- unused-includes
- unknown_typename
- unknown_typename_suggest
- typename_requires_specqual
If:
PathMatch: CM7/.*
2026-02-23 1:16 AM
Hi
could you share some more info about how to get this issue?
2026-02-23 7:15 AM
Hi,
Thank you for your feedback.
To assist us in reproducing the issue where duplicate entry segments appear in the configuration, could you please provide additional details about your scenario?
Our extensions perform configuration automation based on the presence of compile_commands.json files. While it is possible to disable these automations in the settings (stm32cube-ide-build-cmake.intellisense > enableAutomaticConfiguration), we generally do not recommend this.
MNA
2026-02-23 11:15 AM
Hi MNA,
This may be caused by cross-platform collaboration between Windows/OSX/Linux. Other than that, we're not doing anything unique.
2026-02-24 6:13 AM
Unfortunately, we are not able to reproduce the issue. To help us investigate further, could you please provide more details about your setup and scenario? Specifically:
Thank you for your time and cooperation. Once we have this information, we can assist you more effectively.
2026-02-24 5:45 PM
Here's some more detail:
Workstation 1:
Workstation 2:
Both workstations had VS Code and the extension installed within the past 2 weeks.
Project is not multi root, simple project located in GitHub repo. Dual core processor.
.clangd is committed to repository. c_cpp_properties is also committed to repository.
It seems to occur on either opening project, or when rerunning "Setup" in CubeIDE extension.
2026-03-19 4:20 AM
Good morning everyone,
I am experiencing the same issue, under similar conditions. Each time I configure or build the project the .clangd file gets rewritten, deleting my own additions and customoization, and randomly flipping the order between the FSBL and Appli sections.
The same happens for the .vscode/c_cpp_properties.json.
This is very annoying as it pollutes VCS status reports, and causes clangd indexing to stop working as configured, each time a build is triggered.
I am using the 3.8.0 version of STM32CubeIDE for VSCode extension pack, under Windows 11, with a standard single-root workspace. Both .clangd and c_cpp_properties.json files are commited in my VCS (git).
Please let me know if I can assist you in debugging this extremely limiting inconvenient.
Thanks in advance for your support.
2026-03-19 9:50 AM
Hi,
We have been able to reproduce some of the issues previously described on macOS and are actively working on a fix.
@Walt , could you share an example of your own .clangd additions and customizations so we can reproduce the problem on our end.
Thanks,
MNA
2026-03-20 3:22 AM
Hi @Walt ,
Regarding the missing customizations, we identified at least one scenario: when the build directory is cleaned, the compile commands file is deleted, which can temporarily remove the corresponding entry from the indexing configuration (.clangd + cpp_properties) before it is regenerated (with ST defaults) during the next configure step.
We are working on a fix.
With an incremental build (without cleaning), we do not expect this behavior. Could you confirm whether you still see it in that case?
Thanks,
MNA
2026-03-20 4:20 AM
Hi @MNASTM,
Find below my .clangd:
CompileFlags:
Add:
- '-ferror-limit=0'
- '-Wno-implicit-int'
CompilationDatabase: FSBL/build
Diagnostics:
Suppress:
- unused-includes
- unknown_typename
- unknown_typename_suggest
- typename_requires_specqual
If:
PathMatch: FSBL/.*
---
CompileFlags:
Add:
- '-ferror-limit=0'
- '-Wno-implicit-int'
CompilationDatabase: Appli/build
Diagnostics:
Suppress:
- unused-includes
- unknown_typename
- unknown_typename_suggest
- typename_requires_specqual
If:
PathMatch: Appli/.*
---
CompileFlags:
Add:
- '-ferror-limit=0'
- '-Wno-implicit-int'
CompilationDatabase: Appli/build
Diagnostics:
Suppress:
- unused-includes
- unknown_typename
- unknown_typename_suggest
- typename_requires_specqual
If:
PathMatch: Drivers/.*
---
CompileFlags:
Add:
- '-ferror-limit=0'
- '-Wno-implicit-int'
CompilationDatabase: FSBL/build
Diagnostics:
Suppress:
- unused-includes
- unknown_typename
- unknown_typename_suggest
- typename_requires_specqual
If:
PathMatch: Middlewares/ST/STM32_ExtMem_Manager/.*
---
CompileFlags:
Add:
- '-ferror-limit=0'
- '-Wno-implicit-int'
CompilationDatabase: Appli/build
Diagnostics:
Suppress:
- unused-includes
- unknown_typename
- unknown_typename_suggest
- typename_requires_specqual
If:
PathMatch: Middlewares/.*
---
CompileFlags:
Add:
- '-ferror-limit=0'
- '-Wno-implicit-int'
CompilationDatabase: Appli/build
Diagnostics:
Suppress:
- unused-includes
- unknown_typename
- unknown_typename_suggest
- typename_requires_specqual
If:
PathMatch: Lib/.*
All additions get deleted, leaving only the first two sections (Appli/.* and FSBL/*), and sometimes also flipping their order.
However, I cannot deterministically reproduce the error on normal incremental builds. The file gets overwritten only sometimes, and about 20-30s after the compilation ends. So I'm wondering whether the issue may be related to something other than the compilation process itself, perhaps some (periodic?) background task.
Instead, what I seem to be able to reproduce consistently, is the same behaviour appearing each time VSCode is launched from scratch to load the project. I report below an example log from the integrated output console for STM32Cube CMake build, which seems to point to the issue.
2026-03-20 12:14:21.255 [Info] Adding cube-cmake path to environment: c:/Users/mymachineusername/.vscode/extensions/stmicroelectronics.stm32cube-ide-build-cmake-1.44.0-win32-x64/resources/cube-cmake/win32/x86_64
2026-03-20 12:14:32.461 [Info] Activating STM32Cube configurations for the code indexing feature...
2026-03-20 12:14:32.547 [Info] Configuring code indexing for 'd:/Dev/N6'
2026-03-20 12:14:32.737 [Info] Found compile_commands.json file(s) in active project:
2026-03-20 12:14:32.741 [Info] + Appli/build/compile_commands.json
2026-03-20 12:14:32.745 [Info] + FSBL/build/compile_commands.json
2026-03-20 12:14:32.758 [Info] Updating .clangd configuration file (d:/Dev/N6/.clangd)
2026-03-20 12:14:32.789 [Info] Updating c/cpp configuration file (d:/Dev/N6/.vscode/c_cpp_properties.json)
I remain available to contribute in troubleshooting the issue, let me know if I can help further.
Best,
Walter