[IntelliSense C] The "defined" operator is not correctly interpreted by #if

[stb-fr]

Environment

• OS and Version: Windows 10 Entreprise 22H2
• VS Code Version: 1.86.1
• C/C++ Extension Version: 1.18.5

Bug Summary and Steps to Reproduce

​The VSCode editor doesn't seem to interpret #if statements correctly when using the special operator "defined"

Example with the following code:

#define A_DEFINED_VARIABLE          1

#define CHECK_A_DEFINED_VARIABLE    (defined(A_DEFINED_VARIABLE))

#if (defined(A_DEFINED_VARIABLE))
static int MyVar1 = 1;
#endif

#if CHECK_A_DEFINED_VARIABLE
static int MyVar2 = 2;
#endif

int main()
{
    return MyVar1 + MyVar2;
}

IntelliSense considers that MyVar1 is defined, but not MyVar2.

Configuration and Logs

-------- Diagnostics - 2/13/2024, 2:50:33 PM
Version: 1.18.5
Current Configuration:
{
    "name": "Win32",
    "includePath": [
        "${workspaceFolder}/**"
    ],
    "defines": [
        "_DEBUG",
        "UNICODE",
        "_UNICODE"
    ],
    "windowsSdkVersion": "10.0.22621.0",
    "compilerPath": "cl.exe",
    "cStandard": "c17",
    "cppStandard": "c++17",
    "intelliSenseMode": "windows-msvc-x64",
    "compilerPathInCppPropertiesJson": "cl.exe",
    "intelliSenseModeIsExplicit": false,
    "cStandardIsExplicit": false,
    "cppStandardIsExplicit": false,
    "mergeConfigurations": false,
    "compilerPathIsExplicit": false,
    "browse": {
        "path": [
            "${workspaceFolder}/**"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
cpptools version (native): 1.18.3.0
Translation Unit Mappings:
[ C:\Data\Tmp\test.c ]:
    C:\Data\Tmp\test.c
Translation Unit Configurations:
[ C:\Data\Tmp\test.c ]:
    Process ID: 26476
    Memory Usage: 49 MB
    Compiler Path: C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\bin\Hostx64\x64\cl.exe
    Includes:
        C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\include
        C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\atlmfc\include
        C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um
        C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt
        C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\shared
        C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\winrt
        C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\cppwinrt
    Defines:
        _DEBUG
        UNICODE
        _UNICODE
    Standard Version: ms_c17
    IntelliSense Mode: windows-msvc-x64
Total Memory Usage: 49 MB

------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 5027

Other Extensions

No response

Additional context

No response

[browntarik]

Could you please provide the output from the C/C++: Log Diagnostics Command that appears after opening the file you mentioned.

Since I am not easily able to reproduce your scenario, my initial guess is that you somehow have an incompatible compiler and IntelliSense mode or there is an existing IntelliSense bug with one of the modes

[sean-mcmanus]

@stb-fr Your code gives the same error as IntelliSense when compiled with cl.exe -- did you mean to use a different compiler?

[sean-mcmanus]

@stb-fr Are you compiling with the /P flag? cl.exe compiles that code if that flag is used, but it seems like we're not handling that compiler arg correctly.

[sean-mcmanus]

@stb-fr Ignore my last comment -- the /P isn't for actually compiling.

[sean-mcmanus]

@stb-fr I meant to refer to /Zc:preprocessor -- if you add that to compilerArgs then IntelliSense should work correctly. If you don't intend to compile with cl.exe then you should consider changing your compilerPath.

[sean-mcmanus]

@stb-fr Actually, it's a bug -- when /std:c11 or /std:c17 is used, it's supposed to behave as if /Zc:preprocessor is set.

[sean-mcmanus]

@stb-fr Oh, but there's another bug with IntelliSense still giving an error if "/Zc:preprocessor" is used.

Also, cl.exe does give a warning warning C5105: macro expansion producing 'defined' has undefined behavior