Struggling to get stable Intellisense behaviours

[GregTerrell]

I have been using VSCode Arduino (and prior to 2020 VSCode with PlatformIO) to write both commercial libraries and application code for clients for a couple years. As a user of Visual Studio for decades I appreciate the virtues of Intellisense.

I recently started experiencing problems with bool (true, false) and sized int types (uint8_t, uint16_t) generating Intellisense undefines (red-squiggles), which creates a cascade of errors. The number of Intellisense issues reported necessitates either turning Intellisense off or falling back to the Tag Parser (the limited capability of the Tag Parser is better than nothing).

Right now a C file in my current project, that builds without issues, Intellisense generating 199 "Problems". In that same file, the code snippet below on line 2 indicates identifier "uint8_t" is undefined.

uint8_t myProblem;

In the .INO file, references to #defines in a .h file in the {workspace} folder toggle randomly between errors and not errors (all while mouse-over shows the correct value).

In the past, I have added <stdint.h> and <stdbool.h>. I know that has been discouraged in this forum, currently I have only specified <stdint.h> in a Segger non-Arduino C library I use frequently that will not build without it.

Is there any solid advice on the steps to get Intellisense functional in multi-file, multi-library projects?

Thanks,
Greg

[GregTerrell]

Just thinking about the radical difference in c_cpp_properties.json defines (there are about 475 of them) vs. the actual defines added to the GCC command line (there are 27). Seem plausible that this auto generated list is triggering the problem. Deleting the extra defines seems to correct the issue, but with every build they get readded to the c_cpp_properties.json file.

Elsewhere there have been references to the c_cpp_properties.json auto-generation and its "goodness". I generally agree with the virtue of auto-generating c_cpp_properties.json, but a option would be to only generate if missing. So a user can delete it to get it to rebuild, or leave it alone to manually maintain it.

[GregTerrell]

Updating issue in case it can be assistance to others, new information.

The offending "defines" lines being added to c_cpp_properties.json that create the Intellisense issues in C source files.

• __cplusplus=201402L Yes, this seems very old. I have not yet found the GCC binary that could have reported this, there was a old version in Arduinio15\packages\arduino\tools\arm-none-eabi-gcc, but I deleted it. Still reporting old value. Seems arduino board update did not clean up after itself.
• GNUG=9 Not fully understanding the relationship with __cpluscplus but GCC docs indicate relation. This affects only NULL definition Intellisense.

Both of the above need to be removed to stop the Intellisense squiggles. Tried various modern GCC compiler values, does not fix. Since at least the __cplusplus controls resolving stdint types, this seems to be at the root. Other Intellisense errors in my projects are indirectly failing because up the chain there is a bad uint8_t, uint16_t, or bool type definition.

[GregTerrell]

I just discovered the addition of the pre and post build commands (thanks elektronikworkshop). HOWEVER, the vscode-arduino extension rebuilds the Intellisense configuration in c_cpp_properties.json AFTER the vscode-arduino post-build command.

This makes C library source development incredibly painful since the automatic regeneration of the c_cpp_properties.json. If asking the user to Ctrl+Alt+I is too much, at least allow for the automatic Intellisense configuration update to be a setting that can be toggled off by those who need it.

[GregTerrell]

My bad, just discovered Autogenerate c_cpp_properties.json #1183

Add to arduino.json
arduino.disableIntelliSenseAutoGen = true