Skip to main content
LVoze.2
Associate II
February 20, 2026
Question

ISSUE: .clangd is constantly being modified

  • February 20, 2026
  • 4 replies
  • 533 views

.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/.*

 

4 replies

Nawres GHARBI
Technical Moderator
February 23, 2026

Hi  

could you share some more info about how to get this issue?

ST Employee
February 23, 2026

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

LVoze.2
LVoze.2Author
Associate II
February 23, 2026

Hi MNA,

This may be caused by cross-platform collaboration between Windows/OSX/Linux. Other than that, we're not doing anything unique. 

ST Employee
February 24, 2026

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:

  • Version of STM32CubeIDE extension pack
  • Are you using a multi-root workspace?
  • When does the issue occur? (e.g., switching configuration, clean/reconfigure/build, opening the project on a different platform)
  • Is the .clangd file committed to your repository?
  • Any other relevant configuration details

Thank you for your time and cooperation. Once we have this information, we can assist you more effectively.

ST Employee
March 19, 2026

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

 

ST Employee
March 20, 2026

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

Associate
March 20, 2026

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

ST Employee
March 25, 2026

Hi @LVoze.2 , @Walt 

We have implemented several fixes that will be available in the next release:

  • Fixed duplicate .clangd sections created at startup or during project setup
  • Fixed unexpected reordering of .clangd sections
  • Fixed unexpected deletion of additional user-defined .clangd sections

@Walt , we could not reproduce your issue during a normal incremental build, but since the global .clangd update behavior has been reworked and simplified, we expect improvements in various scenarios.

 

In the meantime, you can disable these automations in the settings:

stm32cube-ide-build-cmake.intellisense > enableAutomaticConfiguration

 

MNA