Red Squiggles in VSC

ARich.1 · ‎2025-12-10

I have recently started a project in VSC using an STM32 device. I first used STM32CubeMX to generate code, so that created most of the project. I am using CMAKE.

Initially there was no issue, and everything worked fine after disabling intellisense. However, I have now become plagued by the stubborn red squiggles which refuse to disappear whatever I do. I would prefer to continue using VSC, but will have to ditch it and move to another IDE if this problem does not go away, as I cannot work like this. Further down the file there are many other red squiggles. The project compiles fine, no issues there. An example of the problem:

No matter what I do, the first #include has red squiggles under it. If I change the order of the #includes, then it is always the first one which has the squiggles. settings.json file:

c_cpp_properties.json file:

Any help would be gratefully appreciated, please.

ARich.1 · ‎2025-12-12

Sorry for the missing information, it is not intentional. I just don't want to bombard you with loads of unnecessary stuff like I see periodically in other posts. Here is a larger screenshot, showing the project structure so far; I am porting code into this project from elsewhere. It shows the "Src/System" directory within my project, where control.c is saved. A couple of questions spring to mind: Is the word "System" reserved for other purposes and thus I shouldn't be using it for naming directories? Is the fact that I have my include files in a separate directory called "Inc" an issue?

Only the first #include has red squiggles, but some red squiggles in control.c are from other header files where the #inlcude does not have red squiggles. Further down control.c, where it cannot find things included in the header files:

The problem does not persist in every file, just control.c. This screen shot shows the start of i2c.c, which appears to include FreeRTOSConfig.h successfully with no issues:

The output pane shows the following when opening control.c. I have highlighted two lines which might be of interest. There is more to the output, but no further mention of cancelled requests or errors.

ankes · ‎2025-12-15

Thanks for posting these additional details, and sorry for the delay in my response.

@ARich.1 wrote:
A couple of questions spring to mind: Is the word "System" reserved for other purposes and thus I shouldn't be using it for naming directories? Is the fact that I have my include files in a separate directory called "Inc" an issue?

To answer these questions first, no. The name of the directory does not matter, and neither does it matter if you put header files in "Inc" or right next to the source files.

Now, looking at the output pane from clangd I see a collection of "-I" switches which specify the include directories that clangd is consulting in order to find "FreeRTOSConfig.h". Is this file in one of these directories?

If yes, then the red squiggle under the file usually means "something else" instead of a missing header file. You should hover over the line in VS Code and show what the actual error is.

If no, then try repeating this Output pane exercise with a file which does not yield a similar error. Are the "-I" switches the same or different? If they are different then what makes them so? Are the source files included in different CMakeLists.txt files, maybe?

ARich.1 · ‎2025-12-16

Thank you again for your help.

I tried opening i2c.c, which is working fine, with no red squiggles. This is the output window from STM32Cube clangd, showing that it is looking in the include directories in my project, as required. No issues here.

However, when I do the same thing for control.c, the following output window shows that STM32Cube clangd is not looking any of the include directories for my project, only the directories associated with stm32cubemx:

I have just found that there are two CMakeLists.txt files:

I'm running short of time now, but will look at the two files in more detail when I can.

ARich.1 · ‎2025-12-23

I finally found a solution to eradicate this problem. It appears that clangd can automatically look in some project folders for headers, but not all, especially ones which have not been auto-generated. Adding the following lines to settings.json stopped the red squiggles.

Thank you for your help, it has enabled me to learn much more than I would have done otherwise. Unfortunately, the "Go to Definition" (F12) has stopped working (not as a result of the above additions), so I now have to find out what is causing that.

ankes · ‎2025-12-23

@ARich.1,

I was supposed to reply earlier but ultimately forgot about it. Glad that you found a solution that works for you.

The clangd's output text shows that the two source files likely belong to two different CMake "targets", and the target which "control.c" belongs to does not list the problematic header (or one or more headers this one header refers to) in its "target_include_directories" section.

The reason why compilation succeeds is somewhat obscure science because a header file listed in "target_include_directories" of one target may be marked as transitive, so that it is "inherited" by any target that uses the other one. This is exactly what happens between "STM32_Drivers" object library and the "stm32cubemx" interface library in a run-the-mill STM32 project. This transitive dependency allows "STM32_Drivers" to find the "stm32xxxx_hal_conf.h" file which usually lives in "Core/Inc" directory. In most HAL libraries the "stm32xxxx_hal.h" header tries to include it.

I'm not sure if you tried it already, but you might be able to fix the "root cause" by adding the RTOS headers to the corresponding "target_include_directories" section. Adding them does no harm; having the same header file in multiple places doesn't cause any side-effects or problems, unlike having the same source file in multiple "target_sources" section would.