Intellisense errors for #define values in .C files

[GregTerrell]

Intellisense, in my environment, does not seem to fully see constants defined in a header using #define. This is the same symptoms as described in #969 and is still an issue with VS 0.4.5 (I had to back down from 0.4.6 for a non-related issue it created). I am not 100% sure but it seems to be only a problem if the consumer source file is .c and not a .cpp file. It should be noted that an enum or const defined in that same .h file does not exhibit any Intellisense issues.

If anyone has a c_cpp_properties.json based work around, please share.

Thanks, Greg

[nabelekt]

I have the same problem, in different variations. Adding

            "forcedInclude": [
                "C:\\Program Files (x86)\\Arduino\\hardware\\arduino\\avr\\cores\\arduino\\Arduino.h"
            ],

to c_cpp_properties.json resolved some of them for me.

But, using DxCore , I still see any calls to Serial.printf() get marked with a red squiggly. Ctrl+clicking on printf shows me the definition just fine. Other things here and there have the same behavior. For example, va_start within the printf definition.

In addition to that, when verifying the sketch, I get: [Error] Failed to read or write IntelliSense configuration: {} Haven't seen it be a real problem, but it's annoying.

Here's my c_pp_properties.json file:

{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceFolder}/**",
                "C:\\Users\\nabel\\OneDrive\\Documents\\ArduinoData\\packages\\DxCore\\hardware\\megaavr\\**",
                "C:\\Users\\nabel\\OneDrive\\Documents\\Arduino\\libraries\\**",
                "C:\\Program Files (x86)\\Arduino\\hardware\\arduino\\avr\\**",
                "C:\\Program Files (x86)\\Arduino\\hardware\\tools\\**",
                "C:\\Program Files (x86)\\Arduino\\tools\\**",
                "C:\\Program Files (x86)\\Arduino\\libraries\\**"
            ],
        "forcedInclude": [
            "C:\\Program Files (x86)\\Arduino\\hardware\\arduino\\avr\\cores\\arduino\\Arduino.h"
        ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE",
                "ARDUINO=10816", // Should be updated for version of Arduino IDE installed; https://stackoverflow.com/a/30928558
                "USBCON"
            ],
            "cStandard": "c17",
            "cppStandard": "c++17",
            "intelliSenseMode": "windows-msvc-x64"
        }
    ],
    "version": 4
}

If anyone has IntelliSense working well without these issues, could you share your c_pp_properties.json file?

Edit: I don't think this is unique to .c files. I see it in .ino, .h, and .cpp files as well.

[nabelekt]

I've now done a complete reinstall of the Arduino IDE, making sure that all board packages and libraries were deleted before reinstalling, removed and reinstalled the Arduino VS Code extension, and setup my project directory from scratch. I installed the DxCore board package from the Board Manager within VS Code. I verified my sketch so that the build process created ardino.json and c_pp_properties.json on its own. I added "output": "build", to arduino.json, but otherwise haven't touched those files. And, in my very simple sketch, I can get it to show me that PORTD is undefined and the definition at the same time:

Going through that process did get rid of the [Error] Failed to read or write IntelliSense configuration: {} issue that I was seeing.

VS Code:

Version: 1.62.3 (user setup)
Commit: ccbaa2d27e38e5afa3e5c21c1c7bef4657064247
Date: 2021-11-17T08:11:14.551Z
Electron: 13.5.2
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.22000

Extension version: v0.4.8

[nabelekt]

Another note is that this issue only happens the first time that the affected definition is referenced within a function. Ex.:

The 2nd and later references of Serial or PORTD within the same function do not show up as errors.

Edit: At least it seems like that's usually the case. Here's a contradictory case: