Issue with includes when they are defined by preprocessor macros

[mundodisco8]

Type: LanguageService

Describe the bug

• OS and Version: Windows 10 1909, 18363.752
• VS Code Version: 1.43.2 user setup
• C/C++ Extension Version: 0.27.0
• Other extensions you installed (and if the issue persists after disabling them):
• Does this issue involve using SSH remote to run the extension on a remote machine?:
• When I use the preprocessor to define a header to include, and that header file is in a different folder, Intellisense seems unable to find it, even though said folder is correctly included in the C/C++ config file

Steps to reproduce

I attach a zip file with a workspace where the issue can be reproduced. It's the bare minimum to make it appear. It contains a base folder with one .c (main.c) file and two headers (header1.h and header2.h), and a subfolder with another .c file (anotherfile.c), where the issue is present. New folder.zip
Project
├── main.c
├── header1.h
└── header2.h
. └── Test
. └── anotherFile.c

1. Create a header in a folder (header1.h)
2. Create a .c file in a different folder (anotherFile.c in Test)
3. AnotherFile.c must have an include determined by a preprocessor directive: #include HEADER_NAME
4. Use the C/C++ Properties file to give a value to that preprocessor Macro: "HEADER_NAME=\"header1.h\""
5. See additional context to see on which situations the issue is fixed.

Expected behavior

As header1.h is in my includePath, I expect it to find header1.h

Logs

-------- Diagnostics - 07/04/2020, 11:24:20
Version: 0.27.0
Current Configuration:
{
    "name": "Win32",
    "includePath": [
        "${workspaceFolder}/**"
    ],
    "defines": [
        "_DEBUG",
        "UNICODE",
        "_UNICODE",
        "HEADER_NAME=header1.h"
    ],
    "windowsSdkVersion": "10.0.17763.0",
    "compilerPath": "C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe",
    "cppStandard": "c++17",
    "intelliSenseMode": "msvc-x64",
    "compilerArgs": [],
    "cStandard": "c99",
    "browse": {
        "path": [
            "${workspaceFolder}/**"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
Translation Unit Mappings:
[ C:\Users\joel.santos\New folder\test\anotherfile.c ]:
    C:\USERS\JOEL.SANTOS\NEW FOLDER\TEST\ANOTHERFILE.C
Translation Unit Configurations:
[ C:\Users\joel.santos\New folder\test\anotherfile.c ]:
    Process ID: 26344
    Memory Usage: 11 MB
    Compiler Path: C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe
    Includes:
        C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2017\BUILDTOOLS\VC\TOOLS\MSVC\14.16.27023\INCLUDE
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.17763.0\UM
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.17763.0\UCRT
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.17763.0\SHARED
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.17763.0\WINRT
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.17763.0\CPPWINRT
        C:\USERS\JOEL.SANTOS\NEW FOLDER
    Defines:
        _DEBUG
        UNICODE
        _UNICODE
        HEADER_NAME=header1.h
    Standard Version: c99
    IntelliSense Mode: msvc-x64
Total Memory Usage: 11 MB

Screenshots

Additional context

There are a number of situations where the issue disappears. For example, if I include another header on the same directory than the one that "can't be found", Intellisense can find the header. See anotherFile.c, there's a commented include. If that line is uncommented, Intellisense can find header1.h

Also, if I define the relative path to the header in the macro, Intellisense can find the header:

"defines": [
                [...]
                "HEADER_NAME=\"..\header1.h\""    //This works
                [...]
            ],

My c_cpp_properties.json:

{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceFolder}/**"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE",
                "HEADER_NAME=\"header1.h\""
            ],
            "windowsSdkVersion": "10.0.17763.0",
            "compilerPath": "C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe",
            "cppStandard": "c++17",
            "intelliSenseMode": "msvc-x64"
        }
    ],
    "version": 4
}

[sean-mcmanus]

This a bug with our handling of recursive includes, but it's caused by a design limitation in our "tag parser" which doesn't evaluate macros when getting the list of includes used in a file, so when #include HEADER_NAME is used, our recursive include processing code does not detect the "header1.h" as an include, which causes our recursive include code to remove ${workspaceFolder} from the includePath (i.e. because it thinks the path is unused). A potential workaround is to use something like `"${workspaceFolder}, ${workspaceFolder}/**" to force it to not remove the folder that includes headers that are required.

[mundodisco8]

A potential workaround is to use something like `"${workspaceFolder}, ${workspaceFolder}/**" to force it to not remove the folder that includes headers that are required.

I see, that's a clever trick. That will do for the time being. Thanks!

[kevintruong]

Another issue here is about include a file which defined by macro , and the file content some backslash like bellow

#define INC_FILE "..\hello_world\hello_world.h"
#include INC_FILE 

Look like VSCode will see the \h as a special symbol and then not correct on understanding the INC_FILE like a file include.

[sean-mcmanus]

@kevintruong That code doesn't compile for me. What compiler are you using to compile that?

[h2s0109]

Do you have a plan to fix this bug?

[sean-mcmanus]

@h2s0109 No plans to fix it in the near future.

[h2s0109]

Does it still have no plan?

[sean-mcmanus]

@h2s0109 If we plan to fix this, we'll move it to a Milestone.