Wrong configuration info is used for a C/C++ file that is included by another

I was/I am trying to make "Go To Definition" work in a big project but it did not work. I managed to produce a minimal example of this bug:

Type: LanguageService

Describe the bug

• OS and Version: Arch Linux
• VS Code Version:
  1.49.1
  58bb7b2331731bf72587010e943852e13e6fd3cf
  x64
• C/C++ Extension Version: 1.0.0
• Other extensions you installed (and if the issue persists after disabling them): None
• Does this issue involve using SSH remote to run the extension on a remote machine?: No
• A clear and concise description of what the bug is, including information about the workspace (i.e. is the workspace a single project or multiple projects, size of the project, etc):

File Structure (You can download it here: bugexample.zip):
.
├── child.C : #include "child.H"
├── child.H : #include "hiddenFile.H"
├── compile_commands.json
├── hiddenlib
│ └── hiddenFile.H : empty
├── main.C : #include "child.H" \n int main(){}
└── .vscode
│ └── c_cpp_properties.json

c_cpp_properties.json:

{
    "configurations": [
      {
        "compileCommands": "${workspaceFolder}/compile_commands.json",
      }
    ],
    "version": 4
}

compile_commands.json was generated using bear -- g++ -I./hiddenlib -c main.C:

[
  {
    "arguments": [
      "/usr/bin/g++",
      "-I./hiddenlib",
      "-c",
      "main.C"
    ],
    "directory": "/home/volker/Documents/bugexample",
    "file": "/home/volker/Documents/bugexample/main.C",
    "output": "/home/volker/Documents/bugexample/main.o"
  }
]

Expected behavior and observed behaviour

If I open the folder, open child.H, set my cursor on "hiddenFile.H" and sellect "Go To Definition" it should jump to hiddenlib/hiddenFile.H. Instead it says "No definition for hiddenFile". Also there is a message on startup that says
"child.C" not found in "${workspaceFolder}/compile_commands.json". 'includePath' from c_cpp_properties.json in folder 'bugexample' will be used for this file instead.

Note: You can only reproduce this bug if you don't open main.C and you need to wait a few seconds after startup before trying to "Go To Definition" (around 7 seconds on my machine).

-------- Diagnostics - 10/4/2020, 12:46:46 AM
Version: 1.0.0
Current Configuration:
{
    "compileCommands": "${workspaceFolder}/compile_commands.json",
    "compilerArgs": [],
    "browse": {
        "limitSymbolsToIncludedHeaders": true
    }
}
Translation Unit Mappings:
[ /home/volker/Documents/bugexample/child.C ]:
    /home/volker/Documents/bugexample/child.H
Translation Unit Configurations:
[ /home/volker/Documents/bugexample/child.C ]:
    Process ID: 66481
    Memory Usage: 9 MB
    Compiler Path: /usr/bin/clang
    Includes:
        /usr/include/c++/10.2.0
        /usr/include/c++/10.2.0/x86_64-pc-linux-gnu
        /usr/include/c++/10.2.0/backward
        /usr/local/include
        /usr/lib/clang/10.0.1/include
        /usr/include
        /home/volker/Documents/bugexample
    Standard Version: c++14
    IntelliSense Mode: clang-x64
    Other Flags:
        --clang
        --clang_version=100001
Total Memory Usage: 9 MB

------- Workspace parsing diagnostics -------
Number of folders and files enumerated: 64661
Number of files discovered (not excluded): 60879

Slightly OT: If you know a better tool than vscode-cpptools for finding the definitions in big projects, please tell me.

Reproduziere das Problem mit der angehängten bugexample.zip unter Verwendung von compile_commands.json und .vscode/c_cpp_properties.json wie gezeigt. Beginne damit zu prüfen, wie child.H die Konfiguration erhält, wenn child.C in compile_commands.json fehlt; fertig ist es, wenn Go To Definition von hiddenFile.H zu hiddenlib/hiddenFile.H aufgelöst wird, ohne die Warnung zur Fallback-Konfiguration.