Vscode-cpptools: Why not automatically match the gcc's includePath?

[sky5454]

Type: General

For GCC/MinGW/MinGW64, you can use it to catch the includePath

In Linux, the output as follows

$ gcc -v -x c -E /dev/null 
Using built-in specs.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu /dev/null -mtune=generic -march=x86-64 -fstack-protector-strong -Wformat -Wformat-security
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
# 1 "/dev/null"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "/dev/null"
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=x86-64'

and the IncludePath could be catched easily

#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include

Additional context
In Windows

gcc -v -x c -E NUL

In Linux

$ gcc -v -x c -E /dev/null

and it is also suitable for ARM-Linux-GCC

arm-linux-gcc -v -x c -E /dev/null

Expected behavior
so why add a feature to automatically match the IncludePath,
which makes the C develop environment easy to use.

[bobbrow]

We do this in the extension automatically already. Is something not working for you?

[sky5454]

I found the vscode-cpptools don't use gcc's includePath, vscode-tools just search the header file from the GCC's dir.

If you click the header file:

#include <stdio.h>

while your don't configure the includePath, sometimes it doesn't work well.(search slowly and got other useless results)
vscode-cpptools would took some time to search the dirs, and sometimes it got lots of results. example for #include <stdio.h> got 3 results sometime.

while you configure the includePath which got from the command arm-linux-gcc -v -x c -E /dev/null, the result only one, that is right and fast!!!

[sean-mcmanus]

Can you run the C/C++: Log Diagnostics command and see what Includes are being reported?

[sky5454]

it seems the default configuration of vscode-cpptools includePath ${workspaceFolder}/** break it.

but we know, #include <...> must search the system includePath first. #include "..." search the workspace dir.

the logs

-------- Diagnostics - 12/5/2020, 9:43:56 AM
Version: 1.1.3
Current Configuration:
{
    "name": "Linux",
    "includePath": [
        "${workspaceFolder}/**"
    ],
    "defines": [],
    "cStandard": "c99",
    "cppStandard": "gnu++14",
    "intelliSenseMode": "gcc-arm",
    "compilerPath": "/opt/arm/bin/arm-linux-gcc",
    "compilerArgs": [],
    "intelliSenseModeIsExplicit": true,
    "cStandardIsExplicit": true,
    "cppStandardIsExplicit": true,
    "compilerPathIsExplicit": true,
    "browse": {
        "path": [
            "${workspaceFolder}/**"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
Translation Unit Mappings:
[ /home/yu/myCode/YQ/demoHello.c ]:
    /home/yu/myCode/YQ/demoHello.c
[ /home/yu/myCode/YQ/linux3/linux-3.4.39/arch/powerpc/boot/stdio.c ]:
    /home/yu/myCode/YQ/linux3/linux-3.4.39/arch/powerpc/boot/stdio.h
Translation Unit Configurations:
[ /home/yu/myCode/YQ/demoHello.c ]:
    Process ID: 28526
    Memory Usage: 11 MB
    Compiler Path: /opt/arm/bin/arm-linux-gcc
    Includes:
        /opt/arm/lib/gcc/arm-none-linux-gnueabi/4.5.1/include
        /opt/arm/lib/gcc/arm-none-linux-gnueabi/4.5.1/include-fixed
        /opt/arm/arm-none-linux-gnueabi/include
        /opt/arm/arm-none-linux-gnueabi/libc/usr/include
        /home/yu/myCode/YQ/linux3/linux-3.4.39/arch/arm/include/asm
    Standard Version: c99
    IntelliSense Mode: gcc-arm
    Other Flags:
        --gcc
        --gnu_version=40501
[ /home/yu/myCode/YQ/linux3/linux-3.4.39/arch/powerpc/boot/stdio.c ]:
    Process ID: 28559
    Memory Usage: 10 MB
    Compiler Path: /opt/arm/bin/arm-linux-gcc
    Includes:
        /opt/arm/lib/gcc/arm-none-linux-gnueabi/4.5.1/include
        /opt/arm/lib/gcc/arm-none-linux-gnueabi/4.5.1/include-fixed
        /opt/arm/arm-none-linux-gnueabi/include
        /opt/arm/arm-none-linux-gnueabi/libc/usr/include
        /home/yu/myCode/YQ/linux3/linux-3.4.39/arch/powerpc/boot
    Standard Version: c99
    IntelliSense Mode: gcc-arm
    Other Flags:
        --gcc
        --gnu_version=40501
Total Memory Usage: 21 MB

------- Workspace parsing diagnostics -------
Number of folders and files enumerated: 46467
Number of files discovered (not excluded): 43981
Number of files parsed: 4286

------- 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.

Using: /opt/arm/lib/gcc/arm-none-linux-gnueabi/4.5.1/include/stddef.h
    Alternative: "/home/yu/myCode/YQ/linux3/linux-3.4.39/include/linux"

and when you click it again, it found the <stdio.h> correctly. and the log has nothing change.

[sean-mcmanus]

If Go to Definition on gives 4 results, that means that IntelliSense isn't available to locate the correct file. It sounds like you try again after it's finished processing and it works?

Your diagnostic logging include paths look correct.

The handling of "" versus <> is handled by our IntelliSense process. It just uses a single list of include paths. Is that causing an issue for you? The "**" in your include path invokes recursive includes which will move those includes to end -- you can override that by using a non-recursive include.

[sky5454]

I wonder if it is possible to make two includePath List, the one search the gcc's IncludePath and the other one search the user' configuration likes ${workspaceFolder}/**, so it wouldn't appear the result like this.

[sky5454]

And another problem:
when select "C/C++: arm-linux-gcc build active file"
the launch's miDebuggerPath is still “/usr/bin/gdb”, but it should be same as the arm-linux-gcc's path likes "/opt/arm/bin/arm-linux-gdb"

And

"type": "cppbuild",
            "label": "C/C++: arm-linux-gcc build active file",
            "command": "/opt/arm/bin/arm-linux-gcc",
            "args": [
                "-g",
                "${file}",
                "-o",
                "${fileDirname}/${fileBasenameNoExtension}"
            ],

if change the args, the outpath has no changed.

             "args": [
                "-g",
                "${file}",
                "-o",
                "${fileDirname}/out/${fileBasenameNoExtension}"
            ],

it seems no work.

[sean-mcmanus]

Compilers only use 1 include path list, the "" version just adds the current directory to the top of the include path, which we support. What bug are you experiencing? The multiple stdio.h definitions is unrelated to your request to 2 include paths. I'm not sure why you're getting that. Or was there some other bug you're experiencing?

Are you using 1.1.3 of the C/C++ extension? We fixed some build task bugs with that. Also, you may need to change the task label and the preLaunchTask or use VS Code Insiders to workaround bug https://github.com/microsoft/vscode/issues/109939 .