Header-only fallback incorrectly occurs when system headers are opened using compileCommands

[sean-mcmanus]

Use test.cpp

#include <string>

int main()
{
    std::string s;
}

with some compile_commands.json like

[
    {
        "directory": "<dir>",
        "command": "C:\\PROGRA~2\\MICROS~3\\2017\\ENTERP~1\\VC\\Tools\\MSVC\\1416~1.270\\bin\\Hostx86\\x86\\cl.exe -c sub.cpp",
        "file": "sub.cpp"
    }
]

Then use Go to Definition on std::string.

Bug: The TU for xstring gets opened as a header only fallback instead of using the existing TU for sub.cpp.

This bug doesn't repro when using the CMake Tools configurationProvider.

Bug2 in #5506 is related.

[sean-mcmanus]

This issue doesn't repro on Linux, so the short "~" paths on Windows might be causing the problem?

[sean-mcmanus]

I hit this bug again. It can cause headers from VS 2017 to use VS 2019 includePaths.

[Colengms]

My understanding was that system headers should always use header-only fallback, as it shouldn't be necessary to include the user's symbols in a system header. In populate_filename_cache(), we explicitly exclude any file found under a system path, from the include graph. The scenario in which we are using a source file for a system header TU, would seem to be the bug. Perhaps we are failing to fully populate workspace_folder_data.directories, or failing to set is_system_dir there, when using a custom config provider?

[Colengms]

Sean McManus (@sean-mcmanus) Can you still repro this? I'm not able to repro with a simple example. I see that a system header gets opened into an existing TU that references it (including when that TU got its configuration from a compile_commands.json).