Basic gcc header parsing seems to be broken in Linux

[omercsp]

Type: LanguageService

Describe the bug

• OS and Version: Linux, Fedora 31
• VS Code Version: 1.40.2
• C/C++ Extension Version: 0.26.2

I might got something wrong here, but it looks like the very basic headers parsing is broken.
A simple gcc based "Hello, world!" code written in C shows multiple, some incorrect, references to "stdio.h" (for example). Trying to go to definition of the stdio.h file shows 3 options:

1. /usr/include/bits/stdio.h - a file that should never be included directly (as commented in the header itself), and isn't in gcc's default include path.
2. /usr/include/c++/9/tr1/stdio.h - again, shouldn't be listed here. This should be shown only the included header is <tr1/stdio.h> and the compiler is g++, not gcc.
3. The correct header

Here's a snippet of gcc's output for it's default search path:

$ echo | gcc -xc -E -Wp,-v -
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/9/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/9/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/9/include
 /usr/local/include
 /usr/include
End of search list.

The properties used are just just the default:

{
    "configurations": [
        {
            "name": "Linux",
            "includePath": [
                "${workspaceFolder}/**"
            ],
            "defines": [],
            "compilerPath": "/usr/bin/gcc",
            "cStandard": "c11",
            "cppStandard": "c++17",
            "intelliSenseMode": "gcc-x64"
        }
    ],
    "version": 4
}

It looks like the addon doesn't query gcc for it's include path at all. Indeed, removing the "/usr/bin/gcc" value from the "compilerPath" property didn't change anything about the list of header candidates.

To Reproduce
Create a simple "Hello, world!" C application, with a single <stdio.h> #include

Expected behavior
By default, go to definition of stdio.h should go directly to /usr/include/stdio.h

Screenshots

[sean-mcmanus]

Go to Def on #include doesn't yet use the includePath: #2564

You can use the C/C++: Log Diagnostics command to see what the includePath querying resulted in using. Are the includePaths shown incorrect?

[omercsp]

According to log, yes:

-------- Diagnostics - 12/14/2019, 9:21:54 PM
Version: 0.26.2
Current Configuration:
{
    "name": "Linux",
    "includePath": [],
    "defines": [],
    "compilerPath": "/usr/bin/gcc",
    "cStandard": "c11",
    "cppStandard": "c++17",
    "intelliSenseMode": "gcc-x64",
    "compilerArgs": [],
    "browse": {
        "path": [
            "${workspaceFolder}"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
Translation Unit Mappings:
[ /home/omer/devel/sandboxes/code-check/main.c ]:
    /home/omer/devel/sandboxes/code-check/main.c
Translation Unit Configurations:
[ /home/omer/devel/sandboxes/code-check/main.c ]:
    Process ID: 3283
    Memory Usage: 10 MB
    Compiler Path: /usr/bin/gcc
    Includes:
        /usr/lib/gcc/x86_64-redhat-linux/9/include
        /usr/local/include
        /usr/include
    Standard Version: c11
    IntelliSense Mode: gcc-x64
    Other Flags:
        --gcc
        --gnu_version=90201
Total Memory Usage: 10 MB

It doesn't list the any of the wrong include directories.
I don't get it: goto def of a symbol will open to the correct definition, but goto def of headers doesn't? Symbols are read from headers so I would assume the former implies the latter...

[omercsp]

BTW, going to the printf symbol opens a printf at "/usr/include/bits/stdio2.h".
There is a printf deceleration in "/usr/include/stdio.h".
Surely this isn't the desired behaviour.

[sean-mcmanus]

Yes, Go To Def on headers is not accurate currently -- it's implementation hasn't been updated to use the IntelliSense info.

Go to Declaration will find the declaration of printf in stdio.h. The definition is stdio2.h is "incorrect" (I'm seeing it being "inactive" code)...the reason being how we handle definitions that don't exist in the current TU (we don't do the processing necessary to do a compile/check in the target TU, which is "by design" in that it matches what VS does). The "workaround" is to use the more accurate "Find All References" command, which is slower, but should find the result in stdio.h and not the stdio2.h result.

[omercsp]

So, in a nutshell, the intelisense isn't mature yet; If I'm required for workarounds for such basic tasks, I'd rather not get into this in the first place for now. I'm not saying this as criticism for the work being done here. This is a great project and the progress being made with it is evident. I still hope to use code with this extension as my main C/C++ IDE, but it seems I'll need to wait a bit more for this. (For some bigger than "Hello, World!" projects...)

I'm not sure what you policy for issues here, but at least from my side this one can be closed.

[sean-mcmanus]

Yeah, we're tracking Go to Def on headers at #2564 . One potential workaround is to just type Ctrl+Space at the end of the include before the closing > or " and it should show the correct IntelliSense path in the hover tooltip, or do Go to Def on something you know exists in the header.

[sean-mcmanus]

@omercsp The Go to Def on headers bug is fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/0.28.0-insiders .

[omercsp]

@sean-mcmanus, I can see in 0.28 the headers thing is working.
The "printf" still goes to the wrong place...

[sean-mcmanus]

@omercsp Thanks for letting me know. I repro the issue. I moved it to #5499 .