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.
Bug type: Language Service
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)
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:
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.