got to definition / rename symbol accesses files through symlink source path instead of through symlink (or both)

Bug type: Language Service

• OS and Version: W10 21H1 19044.1466
• VS Code Version: 1.64.1
• C/C++ Extension Version: 1.8.5 Pre-Release
• Other extensions you installed (and if the issue persists after disabling them): all disabled except this one

I have multiple MCU projects that are part of a bigger project that share some common code (like a clock control module). I have one directory outside of those projects symlinked to inside the source directory inside those projects. Each sub-project is opened through VSCode as a folder when editing it; I don't just open the parent dir (I could understand the current behaviour then).

For example: (names not matching later screenshots)

/
├ SharedSource ←───────────────────┐
├ ProjectA/[Firmware]/src/shared ──┤
└ ProjectB/[Firmware]/src/shared ──┘
[ ] = opened in VSCode

This works pretty well with one exception. When using for example "Go to Definition"/ctrl-click the file is opened through the symlink's origin path, not through the symlink itself (it gives me the choice which one to open if I opened the file through the explorer panel, i.e. through the symlink, before).

For example:

File: "/SharedSource/timer.c"
Expected Behaviour: open "/..../shared/timer.c" through symlink
Actual Behaviour: opens "/SharedSource/timer.c" directly (which is outside the opened folder), not through symlink

This by itself isn't that big of a problem, but it gets pretty messy when trying to "Rename Symbol" stuff.

When I open a file through the explorer panel, so through the symlink and then rename, lets say, a function, this happens:

... and if there isn't anything that causes the refactor panel to open so I can uncheck stuff it leads to this (best case with almost no references in other files):

... which means I always have to close at least one duplicate of each affected file. If there are some cross-references between files inside the symlinked folder it gets worse.

It seems like the files are originally just indexed through the source path, but as soon as I open it through the symlink it now is indexed twice. If a sufficient amount of files with cross references is indexed twice the above happens.

Interestingly this doesnt happen to any files from a subfolder of "SharedSource". There it just uses the symlink each time, ignoring the files from the symlink's source path. I didn't test this extensively though.