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.