Extension does not detect imports in 1.6.0

[okuma10]

Bug type: General

#include does not include .h files in a C project. Extension version: 1.6.0. Working extension where the bug is not present is 1.4.1. I reverted to 1.4.1 (default - to stop it updating automatically) and it works just fine.

[sean-mcmanus]

This issue doesn't repro in general (i.e. our team isn't able to repro it, nor have we received other bug reports like this yet), so we'll need more info. Are you able to provide more repro info, such as some simple test project or output from running C/C++: Log Diagnostics? Does the bug happen in 1.5.1?

What exactly do you mean by "does not include .h files"? What error do you see? Do you see any crash messages in the C/C++ output logging?

[okuma10]

Not sure how reproducible it is. I'm following a vulkan tutorial But here is what I get This is on 1.6.0:

Same thing but on 1.51(I've tried it and that works as well). File was not modified. The only thing I did was to click unistnall>install another version>1.5.1 from the extension settings: Now all header includes work as they should. So to me there is something that changed in 1.6.0, because I did not change anything, yet in 1.5.1 it works but not in 1.6.0. More over the first time I saw this I was on vacation for a week. So 7days no one had even powered the PC. And when I got back and booted it up(no windows updates performed) it automatically updated the extension to 1.6.0 and now the imports don't work.

[sean-mcmanus]

Can you try adding "*.inl": "c" to your files.associations setting -- it looks like we're treating that as C++ instead of C.

Also, it seems like you're not getting any "missing header" error messages, right? That implies that the header may be found, but the definitions are getting skipped or removed. What do you get when you do a Go to Definition on the missing symbol?

Also, what OS and compiler are you using? Can you use something like /usr/bin/gcc -std=c17 -E -dD <sourceFile.c> > sourceFile.out.c to generate a preprocessed file and then look for IntelliSense errors that appear to be related to the missing defines and/or look if you see the definitions in the output (FYI, some errors are expected and can be ignored). Using go to definition on the #include lines is another alternative.

Also, if you can compare the C/C++: Log Diagnostics output that you get with 1.6.0 versus 1.5.1 that could also indicate if something has changed in regards to what we pass to our parser or if the regression is with our parser itself.

Also, we changed C_Cpp.default.compilerPath to be machine-overridable scope, so if you have that set as a user setting it won't be used (which could cause the wrong defines to be set).

[nolancasimir]

I have this same issue. I can hit F12 and go to the definition of a defined type, but intellisense says the type does not exist. I also use C and not C++.

This is the error

This is the peek window

[sean-mcmanus]

@nolancasimir Can you run C/C++: Log Diagnostics and see if the header file with the definition is being associated with the same TU as the source file?

And what OS/compiler are you using? That could help narrow down the repro.

[nolancasimir]

Is this in the Output tab, where you select C/C++? That section is blank for me.

I am using Windows 10, we compile with clang x64. My friend did not have this issue until he updated vs code to the latest version (1.59.1). He had a version at least a few months old before updating.

[sean-mcmanus]

The C/C++: Log Diagnostics command is run via the Command Palette.

1.6.1 has a 1.58.0 VS Code dependency, so if your friend had an older version, then their latest C/C++ extension version would have been 1.5.1 (other than that, the VS Code itself is not expected to have an impact).

Are only certain defines not working? Is anyone able to determine what is special about those defines?

Here's what I'm seeing: Compiler Path: C:\Program Files\LLVM\bin\clang.exe Includes: C:\PROGRAM FILES\LLVM\LIB\CLANG\12.0.0\INCLUDE C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PREVIEW\VC\TOOLS\MSVC\14.30.30423\INCLUDE C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PREVIEW\VC\TOOLS\MSVC\14.30.30423\ATLMFC\INCLUDE C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.19041.0\UCRT C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.19041.0\SHARED C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.19041.0\UM C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.19041.0\WINRT

Defines: _DEBUG UNICODE _UNICODE Standard Version: c17 IntelliSense Mode: windows-clang-x64 Other Flags: --clang --clang_version=120000 Total Memory Usage: 15 MB

[sean-mcmanus]

If you set the C_Cpp.intelliSenseCacheSize to 0 (temporarily) to see if that fixes it, that would rule out a header cache corruption problem.

[nolancasimir]

Setting C_Cpp.intelliSenseCacheSize does not fix the issue in this case

[sean-mcmanus]

Is anyone able to repro this with some sort of code sample I can try? The samples I have tried aren't reproing it.

[nolancasimir]

I also ran the diagnostics, what are you looking for in that specifically. My company would not like if I were to copy all the information in the output.

Here are a few snippets that should be safe Process ID: 24328 Memory Usage: 196 MB Compiler Path: C:\Program Files\LLVM\7.0.1\bin\clang.exe Includes: C:\PROGRAM FILES\LLVM\7.0.1\LIB\CLANG\7.0.1\INCLUDE C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\PROFESSIONAL\VC\TOOLS\MSVC\14.29.30037\INCLUDE C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\UCRT C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\SHARED C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\UM C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\WINRT .... Defines: _DEBUG UNICODE _UNICODE _CORTEX_A Forced Includes: ......./dev/.vscode/vscode_preinclude.h Standard Version: c89 IntelliSense Mode: windows-clang-x64 Other Flags: --clang --clang_version=70001 Total Memory Usage: 196 MB

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

------- Potential include path issues -------- Some headers exist in multiple locations. If IntelliSense is behaving incorrectly, try adding one of the alternate paths to the "includePath" in your configuration in c_cpp_properties.json to override the automatic path discovery for that header.

[sean-mcmanus]

We're looking for output that is unusual. I assume the "..." contains the correct list of includes. I've tried with a forced include and c89 and I still don't repro the issue. I'm using clang 12 though...it's possible the older clang might be required, although that seems unlikely.

In your logging, does the "Translation Unit Mappings:" section look correct after opening the source file and the header with the definition that is missing? You should see it list the source and header files in the same TU and not 2 different TUs.

Also in the header file that has the definition missing, doe IntelliSense appear to be working, i.e. does hovering over a 0 show (int)0? Or does the C/C++ logging pane (not the diagnostics one) show any "crash" messages?

[sean-mcmanus]

Also, the "Some headers exist in multiple locations. " implies you're using recursive includes, which is non-deterministic in regards to which header it picks up if there exist multiple headers with the same name, so 1.6.1 might be picking up a different/incorrect header (i.e. one that doesn't have the definition)...you would fix that by adding the path to the correct header to override the recursive include selected one.

[nolancasimir]

The includes seem correct

The TU section is the same after opening both files

Intellisense seems to work on the header file, there are no errors, and I see (int)0 when hovering over a zero.

Where would I be able to add the header path to override the recursive includes?

[nolancasimir]

Also, here is this snippet if it is useful

-------- Diagnostics - 8/25/2021, 3:30:21 PM Version: 1.6.0 Current Configuration: { "name": "Win32", "includePath": [ "${workspaceFolder}/" ], "defines": [ "_DEBUG", "UNICODE", "_UNICODE", "_CORTEX_A" ], "compilerPath": "C:\Program Files\LLVM\7.0.1\bin\clang.exe", "cStandard": "c89", "cppStandard": "c++98", "forcedInclude": [ "${workspaceFolder}/.vscode/vscode_preinclude.h" ], "compilerPathIsExplicit": true, "cStandardIsExplicit": true, "cppStandardIsExplicit": true, "intelliSenseModeIsExplicit": true, "compilerArgs": [], "browse": { "path": [ "${workspaceFolder}/" ], "limitSymbolsToIncludedHeaders": true } } Translation Unit Mappings:

[sean-mcmanus]

If go to definition on the #include opens the correct file (and the header path in the logging looks correct), then that implies recursive includes selected the correct one, but you could override that by adding another path to the includePath.

So is the definition recognized by IntelliSense in the header file, but not the source file? That would imply that it is somehow getting undefined.

[nolancasimir]

Go to definition goes to the correct file.

adding the .h file to my vscode_preinclude.h file seems to fix the typedefs, although it is not fixing an enum value later in the file. It is not directly included in the file, but is included three header files deep. Could that potentially cause an issue?

[sean-mcmanus]

If some of the definitions in the header are being found by IntelliSense, but other definitions are not, that suggests that our parser could be failing either on or before those definitions.

I've tested with headers 5+ levels deep, so I don't think that could be related.

Others on our team may be able to try out some open source C projects to see if they can locate a repro.

[v-ericawu]

Sorry, in C/C++ Extension 1.5.1 and 1.6.0, we did not reproduce your problem, and IntelliSense works normally. For further investigation, can you share the demo project with us?

[okuma10]

No problem sharing the code...I'm a bit noobish at Github so I hope I got this right: https://github.com/okuma10/Kohi.git

As for the includes, on 1.6.0 I get errors that my declarations(be it structs, typedefs or functions from .h files) are not declared. Also when building the project it says it cannot find the linked .h files. As for the .inl files. Yes they appear to be detected as C++ files, but that wasn't a problem up until 1.6.0.

[nolancasimir]

Rolling this back to version 1.5.1 fixes the issue for me, so it must have been broken in 1.6.0. Is there a way to lock the version so I can still use auto-update without having to revert the version of this extension each time I re-open vs code?

[okuma10]

@nolancasimir I changed from "insiders" to "default" on the extension settings. It won't auto update but you can still install the 1.5.1

[nolancasimir]

Another note, someone on my team was also able to fix this by deleting the following line in c_cpp_properties.json

"compilerPath": "\"C:\Program Files\LLVM\12.0.0\bin\clang-cl.exe\"",

[v-ericawu]

@okuma10 We not repro you issue and not sure if steps are correct. Could you help to verify the following issue?

1. With 1.6.0 version extension, the following code did not report an error(Same results for other extended versions)
2. The following error seems to be due to the inability to recognize the "vulkan_types.inl" file. Do you have a repro for this problem?

If our steps are not correct, could you share the precise repro steps?

[okuma10]

the vulkan.inl file is just declaration of structs like vulkan_context as you pointed out. The vulkan headers are part of the Vulkan SDK. You have to install Vulkan SDK and the C/CPP link settings will detect those. Also what @nolancasimir said:

Another note, someone on my team was also able to fix this by deleting the following line in c_cpp_properties.json

"compilerPath": ""C:\Program Files\LLVM\12.0.0\bin\clang-cl.exe"",

worked and every time I removed the "compiler path" in the project's c_cpp_properties.json, and it recognized the vulkan headers. Everytime I added that line the errors came back again.(in 1.6.0) So that's a solution, but why having it didn't matter in 1.5.1 and it does now in 1.6.0

[sean-mcmanus]

When you remove "compilerPath": ""C:\Program Files\LLVM\12.0.0\bin\clang-cl.exe" what compiler ends up getting used when you run C/C++: Log Diagnostics? What compiler is supposed to be used (i.e. which are you using to build)? The difference in behavior might be due to a bug fix or it might be a new bug.

[nolancasimir]

-------- Diagnostics - 8/27/2021, 2:44:19 PM Version: 1.6.0 Current Configuration: { "name": "Win32", "includePath": [ "${workspaceFolder}/" ], "defines": [ "_DEBUG", "UNICODE", "_UNICODE", "_CORTEX_A" ], "cStandard": "c89", "cppStandard": "c++98", "intelliSenseMode": "windows-msvc-x64", "forcedInclude": [ "${workspaceFolder}/.vscode/vscode_preinclude.h" ], "compilerPathIsExplicit": false, "cStandardIsExplicit": true, "cppStandardIsExplicit": true, "intelliSenseModeIsExplicit": false, "macFrameworkPath": [], "windowsSdkVersion": "10.0.18362.0", "compilerArgs": [], "compilerPath": "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30037\bin\Hostx64\x64\cl.exe", "browse": { "path": [ "${workspaceFolder}/" ], "limitSymbolsToIncludedHeaders": true } }

[sean-mcmanus]

So do you build your project with cl.exe or clang-cl? They are different compilers, although clang-cl attempts to emulate cl.exe in some regards.

[georgev93]

Not to confuse things too much, but I can confirm that my Intellisense is not working properly in v1.6.0 in the same manner that has been described in this thread. I've rolled back to v1.5.1 and everything is working perfectly.

To expend a bit more, I have noticed when I use a struct defined in another file in my project (a .h file located within the project directory), it is showing up as undefined (red squiggles). Then as I hover over it, the error remains. I can ctrl+click it to show its definition elsewhere in the project, which VS code correctly identifies. When I open up the file that the struct has been defined in, then I navigate back to the original file with the error, the error remains. BUT if I then hover over the symbol (not ctrl+click, just hover) the error goes away after a few seconds. Then I can close the file that the struct has been defined in, and the error returns!

All of this occurs after intellisense parsing has completed. I've also been able to recreate this with symbols from system headers, such as uint8_t.

[okuma10]

This is my Log Diagnostics without the line

-------- Diagnostics - 8/28/2021, 3:16:59 PM
Version: 1.6.0
Current Configuration:
{
    "name": "Win32",
    "includePath": [
        "${workspaceFolder}/engine/src/**",
        "C:\\VulkanSDK\\1.2.176.1/include"
    ],
    "defines": [
        "_DEBUG",
        "UNICODE",
        "_UNICODE",
        "KEXPORT"
    ],
    "windowsSdkVersion": "10.0.19041.0",
    "cStandard": "c17",
    "cppStandard": "c++17",
    "intelliSenseMode": "clang-x64",
    "compilerPathIsExplicit": false,
    "cStandardIsExplicit": true,
    "cppStandardIsExplicit": true,
    "intelliSenseModeIsExplicit": true,
    "macFrameworkPath": [],
    "compilerArgs": [],
    "compilerPath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\VC\\Tools\\MSVC\\14.29.30037\\bin\\Hostx64\\x64\\cl.exe",
    "browse": {
        "path": [
            "${workspaceFolder}/engine/src/**",
            "C:\\VulkanSDK\\1.2.176.1/include",
            "${workspaceFolder}"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
No active translation units.

[okuma10]

To add to the thread, I've also talked with the creator of the series, (about some issues I was stuck with). He also reported the same issue and that he also reverted back to 1.5.1

[sean-mcmanus]

@okuma10 Your log diagnostics output shows "No active translation units", i.e. it needs to be run after opening a file and having the IntelliSense finished parsing it. The most important information we're looking for is the IntelliSense mapping.

We're not sure if this is a bug yet or not. If your code isn't compilable with clang-cl and your compilerPath is set to that, then the results could be unpredictable. Is anyone reproing a bug with the compilerPath set to cl?

[travisvroman]

I'll chime in on this. I'm the creator of the series @okuma10 is referring to.

Here is my repo: https://github.com/travisvroman/kohi

1.5.1 works perfectly, as expected. If I upgrade to 1.6, I get 'identifier x is undefined' errors all over the place; not just with Vulkan includes but with includes local to the project as well. I'm guessing it's some sort of cascade effect, but I haven't been able to narrow it down.

Note: I am using just clang.exe, not clang-cl.exe, so I don't believe that's where the problem arises.

Here are the diagnostics, with the compilerPath set:

-------- Diagnostics - 10/5/2021, 12:39:22 PM
Version: 1.6.0
Current Configuration:
{
    "name": "Win32",
    "includePath": [
        "${workspaceFolder}/engine/src/**",
        "C:\\VulkanSDK\\1.2.182.0/include"
    ],
    "defines": [
        "_DEBUG",
        "UNICODE",
        "_UNICODE",
        "KEXPORT"
    ],
    "windowsSdkVersion": "10.0.18362.0",
    "compilerPath": "C:\\Program Files\\LLVM\\bin\\clang.exe",
    "cStandard": "c17",
    "cppStandard": "c++17",
    "intelliSenseMode": "clang-x64",
    "compilerPathIsExplicit": true,
    "cStandardIsExplicit": true,
    "cppStandardIsExplicit": true,
    "intelliSenseModeIsExplicit": true,
    "compilerArgs": [],
    "browse": {
        "path": [
            "${workspaceFolder}/engine/src/**",
            "C:\\VulkanSDK\\1.2.182.0/include",
            "${workspaceFolder}"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
Translation Unit Mappings:
[ C:\kohi\code\engine\src\renderer\vulkan\vulkan_backend.c ]:
    C:\KOHI\CODE\ENGINE\SRC\RENDERER\VULKAN\VULKAN_BACKEND.C
Translation Unit Configurations:
[ C:\kohi\code\engine\src\renderer\vulkan\vulkan_backend.c ]:
    Process ID: 25420
    Memory Usage: 27 MB
    Compiler Path: C:\Program Files\LLVM\bin\clang.exe
    Includes:
        C:\VULKANSDK\1.2.182.0\INCLUDE
        C:\PROGRAM FILES\LLVM\LIB\CLANG\12.0.0\INCLUDE
        C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\VC\TOOLS\MSVC\14.28.29333\INCLUDE
        C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\VC\TOOLS\MSVC\14.28.29333\ATLMFC\INCLUDE
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\UCRT
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\SHARED
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\UM
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\WINRT
        C:\KOHI\CODE\ENGINE\SRC
    Defines:
        _DEBUG
        UNICODE
        _UNICODE
        KEXPORT
    Standard Version: c17
    IntelliSense Mode: windows-clang-x64
    Other Flags:
        --clang
        --clang_version=120000
Total Memory Usage: 27 MB

------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 4118
Number of files parsed: 514

I have also tried unsetting this, but it seems to default to using cl.exe, which isn't what I want.

Here are the diagnostics without 'compilerPath' set, as suggested in the comments above:

-------- Diagnostics - 10/5/2021, 12:44:57 PM
Version: 1.6.0
Current Configuration:
{
    "name": "Win32",
    "includePath": [
        "${workspaceFolder}/engine/src/**",
        "C:\\VulkanSDK\\1.2.182.0/include"
    ],
    "defines": [
        "_DEBUG",
        "UNICODE",
        "_UNICODE",
        "KEXPORT"
    ],
    "windowsSdkVersion": "10.0.18362.0",
    "cStandard": "c17",
    "cppStandard": "c++17",
    "intelliSenseMode": "clang-x64",
    "compilerPathIsExplicit": false,
    "cStandardIsExplicit": true,
    "cppStandardIsExplicit": true,
    "intelliSenseModeIsExplicit": true,
    "macFrameworkPath": [],
    "compilerArgs": [],
    "compilerPath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.28.29333\\bin\\Hostx64\\x64\\cl.exe",
    "browse": {
        "path": [
            "${workspaceFolder}/engine/src/**",
            "C:\\VulkanSDK\\1.2.182.0/include",
            "${workspaceFolder}"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
Translation Unit Mappings:
[ C:\kohi\code\engine\src\renderer\vulkan\vulkan_backend.c ]:
    C:\KOHI\CODE\ENGINE\SRC\RENDERER\VULKAN\VULKAN_BACKEND.C
Translation Unit Configurations:
[ C:\kohi\code\engine\src\renderer\vulkan\vulkan_backend.c ]:
    Process ID: 23200
    Memory Usage: 35 MB
    Compiler Path: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\bin\Hostx64\x64\cl.exe
    Includes:
        C:\VULKANSDK\1.2.182.0\INCLUDE
        C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\VC\TOOLS\MSVC\14.28.29333\INCLUDE
        C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\VC\TOOLS\MSVC\14.28.29333\ATLMFC\INCLUDE
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\UM
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\UCRT
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\SHARED
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\WINRT
        C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.18362.0\CPPWINRT
        C:\KOHI\CODE\ENGINE\SRC
    Defines:
        _DEBUG
        UNICODE
        _UNICODE
        KEXPORT
    Standard Version: ms_c17
    IntelliSense Mode: windows-msvc-x64
Total Memory Usage: 35 MB

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

I hope this helps.

[github-actions[bot]]

Hey @sean-mcmanus, this issue might need further attention.

@okuma10, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[okuma10]

oh sorry I'm not aware that I should had closed the issue. Yes in latest version the issue appears to be resolved Thanks for all the hard work.