System include paths should always be after recursive include paths

[mrx23dot]

Type: Bug

#include "adc.h"

includes adc.h from minGW first (at least for browsing), instead of local folder,

if I wanted that then I would use
#include <adc.h>

Extension version: 1.17.5
VS Code version: Code 1.73.1 (6261075646f055b99068d3688932416f2346dd3b, 2022-11-09T04:27:29.066Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Sandboxed: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz (8 x 2304)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	undefined
Memory (System)	15.81GB (6.69GB free)
Process Argv
Screen Reader	no
VM	0%

[sean-mcmanus]

Using IntelliSense, #include "" prioritizes the local folder in regards to which adc.h file it chooses, as can be verified via using Go to Definition on the include line or running C/C++: Log Diagnostics. What do you mean by "at least for browsing"? Can you provide more repro details or the Log Diagnostics output?

[mrx23dot]

When I was viewing adc.c it was complaining about missing types (located in adc.h next to it),
and when I clicked in it #include "adc.h" it open adc.h from gcc include directory.

After a reboot everything worked fine, weird.
I will investigate further when/if it comes back.
Cheers

This is the debug output now that it's working:

-------- Diagnostics - 2023. 10. 02. 22:13:40
Version: 1.14.5
Current Configuration:
{
    "name": "Win32",
    "includePath": [
        "d:\\DRIVE\\Projects\\xxx\\src/**"
    ],
    "defines": [
        "_DEBUG",
        "UNICODE",
        "_UNICODE"
    ],
    "cStandard": "c17",
    "cppStandard": "gnu++14",
    "intelliSenseMode": "windows-gcc-x64",
    "intelliSenseModeIsExplicit": false,
    "cStandardIsExplicit": false,
    "cppStandardIsExplicit": false,
    "mergeConfigurations": false,
    "compilerPath": "D:\\Cool\\DevEnv\\TDMGCC64\\bin\\gcc.exe",
    "compilerPathIsExplicit": false,
    "browse": {
        "limitSymbolsToIncludedHeaders": true,
        "path": [
            "${workspaceFolder}/**"
        ]
    }
}
Translation Unit Mappings:
[ D:\DRIVE\Projects\xxx\src\adc\adc.c ]:
    D:\DRIVE\Projects\xxx\src\adc\adc.c
    D:\DRIVE\Projects\xxx\src\adc\adc.h *
Translation Unit Configurations:
[ D:\DRIVE\Projects\xxx\src\adc\adc.c ]:
    Process ID: 8604
    Memory Usage: 65 MB
    Compiler Path: D:\Cool\DevEnv\TDMGCC64\bin\gcc.exe
    Includes:
        D:\Cool\DevEnv\TDMGCC64\lib\gcc\x86_64-w64-mingw32\10.3.0\include
        D:\Cool\DevEnv\TDMGCC64\include
        D:\Cool\DevEnv\TDMGCC64\lib\gcc\x86_64-w64-mingw32\10.3.0\include-fixed
        D:\Cool\DevEnv\TDMGCC64\x86_64-w64-mingw32\include
        D:\DRIVE\Projects\xxx\src\main
        D:\DRIVE\Projects\xxx\src\dio
    Defines:
        _DEBUG
        UNICODE
        _UNICODE
    Standard Version: c17
    IntelliSense Mode: windows-gcc-x64
    Other Flags:
        --gcc
        --gnu_version=100300
Total Memory Usage: 65 MB

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

[mrx23dot]

I managed to recreate on Windows 10

Extension version: 1.17.5
VS Code version: Code 1.73.1 (6261075646f055b99068d3688932416f2346dd3b, 2022-11-09T04:27:29.066Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Sandboxed: No

C/C++: Log Diagnostics is not offered in cmd palette.

[github-actions]

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

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

[github-actions]

This issue has been closed because it needs more information and has not had recent activity.

[mrx23dot]

Please don't close this.

I don't know what else can be more important than locating the correct include files.

[bobbrow]

I think I know what's going on here. It's because we prioritize exact paths over recursive includes. When we add the compiler include paths at the end they are being prioritized ahead of the workspace include paths, but compiler paths should always be last.

I thought this worked in the past, but it's been a while since I worked on this part of the code. We need to investigate what's going on here and make sure the compiler includes are at the end.

EDIT: for reference

    Includes:
        D:\Cool\DevEnv\TDMGCC64\lib\gcc\x86_64-w64-mingw32\10.3.0\include
        D:\Cool\DevEnv\TDMGCC64\include
        D:\Cool\DevEnv\TDMGCC64\lib\gcc\x86_64-w64-mingw32\10.3.0\include-fixed
        D:\Cool\DevEnv\TDMGCC64\x86_64-w64-mingw32\include
        D:\DRIVE\Projects\xxx\src\main
        D:\DRIVE\Projects\xxx\src\dio