vscode-cpptools
vscode-cpptools copied to clipboard
microsoft
Go to declaration always shows 2 files, relative and absolute paths
Type: LanguageService
Describe the bug
- OS and Version: Ubuntu 14.04.5
- VS Code Version: 1.24.1
- C/C++ Extension Version:
- Other extensions you installed (and if the issue persists after disabling them): yes
- A clear and concise description of what the bug is.
The issue is that my workspace folders setting contains only the current dir "." and ctrl+p open file using the relative path, BUT, the problems tab show the problems in the same file but with the absolute path and when I click on a problem, it opens the same file twice. 1 with relative and 1 with absolute path. It also happens with "goto declaration", it shows 2 files, 1 with relative, and with absolute path. Is there a way to use only relative or absolute path?
Steps to Reproduce:
- Open file using ctrl+p
- Click on the of the problems in that file from the problems tab
Expected behavior
If the file already open, it should navigate from the problems tab to the open file
Screenshots
goto reference screen shot:
This isn't an issue with our C/C++ extension is it? Can you file a VS Code bug at https://github.com/Microsoft/vscode? Who is outputting the absolute paths?
Sometimes this happens during a build task. Are you building your code when these two references appear, or just opening files wth ctl+p? If not, can you share your workspace folder settings? I'm not sure what exactly you mean when you say it contains only the current dir ".".
This isn't an issue with our C/C++ extension is it? Can you file a VS Code bug at https://github.com/Microsoft/vscode? Who is outputting the absolute paths?
cpptools is my only extension which shows errors in the problems window with absolute path. for example, I have 'code spell checker' extension which always shows the relative path. And as I mentioned, it also happens with cpptools goto reference
thanks for your help.
Sometimes this happens during a build task. Are you building your code when these two references appear, or just opening files wth ctl+p? If not, can you share your workspace folder settings? I'm not sure what exactly you mean when you say it contains only the current dir ".".
this is my workspace setting file: { "folders": [ { "path": "." } ], }
I've only included the workspace folder, I've also tried replacing the "." with the absolute path. I build the project in a way that all the source code I need has a symbolic link in the workspace folder. cause I have a very big project and I didn't want IntelliSense to tag all of it. So my workspace contains the workspace file and a couple of symbolic links.
thanks for your help.
I am not able to observe absolute paths coming from our extension. What errors are appearing the problem window exactly? Our IntelliSense errors and gcc problem matcher use workspace relative paths. I see Go to Declaration using relative paths as well.
Does this problem occur with your particular setup or does it repro for a newly created folder? It sounds like the symlink may be the cause.
I am not able to observe absolute paths coming from our extension. What errors are appearing the problem window exactly? Our IntelliSense errors and gcc problem matcher use workspace relative paths. I see Go to Declaration using relative paths as well.
Does this problem occur with your particular setup or does it repro for a newly created folder? It sounds like the symlink may be the cause.
You are right, it seems to be the symbolic link causing that. I tried w/o them and the issue is gone. Is there a way to workaround it?
I don't know a workaround yet. It sounds like a bug. On Linux with a symlinked folder, I'm seeing errors getting shown for the symlink target, causing squiggles to not appear in the current file, and a different file to get opened when the erorr window is clicked (i.e. the symlink target) -- is that the same bug you're seeing? I don't understand how to repro the absolute path in the Go to Declaration.
I have also encountered similar issues, and I previously filed the issue in the vscode repo, which can be seen at this link. I think this may be helpful.
I have also encountered similar issues, and I previously filed the issue in the vscode repo, which can be seen at this link. I think this may be helpful.
That issue has been closed as being a problem with this extension.
I have also encountered similar issues, and I previously filed the issue in the vscode repo, which can be seen at this link. I think this may be helpful.
That issue has been closed as being a problem with this extension.
Just fyi, I'm experiencing almost this exact same issue, but I do not have this extension installed. I filed an issue for vscode which was closed as a duplicate, though I disagree with that assessment (the issue identified as the dup seems different). No resolution at this time.
@dev-guy I don't think this issue is related to yours. I think you want https://github.com/microsoft/vscode-cpptools/issues/2375 and https://github.com/microsoft/vscode-cpptools/issues/4206 . I did look into fixing our symlink issues and wrote up a walkthrough on the changes required, but it was too big of a change, so it got pushed back until we can finish other higher priority tasks we're working on (e.g. new multi-root implementation).
What Microsoft employee do you want us to talk with? We usually communicate with the VS Code team via GitHub or email, because most of them are not working at the same time as our C/C++ team.
@occia There are no definitive plans currently (i.e. it's not on our next milestone), but we have a number of symlink-related bugs that would be good to fix eventually, so this would be part of that. More upvotes would help.
@Victsz There is no solution yet. If this becomes fixed, we'll most likely mark this issue as "Fixed (pending release)" and close it.
Same problem on Windows. The problem is also observed when renaming variables using the F2 hotkey. When searching for a variable, studio finds it in the file with an absolute path and a relative one.
I've also encountered this bug more than once. Client runs on Windows, server runs on Linux. Some observations:
- It has nothing to do with sym links - I don't have any.
- Pressing F12 opens the file with absolute path - even if the requested location is in the active file.
- Find in Files lists two findings (in the identical file): one in the workspace folder with relative path and one in an "Other Files" section with absolute path. However this is not reproducible - it only happens sometimes. But when there is no "Other Files" section, then also F12 stops working ("No definition found for ...").
- It somehow depends on the server. I have one remote location, where it never happens. On a second one it happens independently of the opened workspace folder. Maybe it is tied to the server compiler (but then: why does it also happen with "Find in Files"?)
- The bug is really annoying. Sometimes I edit both files by accident. Best case: VSC warns me about a conflict when saving. But it has also happend, that I've lost some work.
@krzikalla It's possible the server that repros the bug has some old file paths in the database, so you might want to try running a C/C++: Reset IntelliSense Database from the Command Palette. Otherwise, if you could set C_Cpp.loggingLevel to "Debug" and look at the paths in the C/C++ logging to see how the paths are different, that might help.
Thanks for the advice. At least it helped pinning down the reason: it is a problem with symbolic links after all. Only, that the symlink is embedded deep inside the home folder structure (nothing I can change). It is /home/userid -> /home/h0/userid The thing is, that my workspace resides on the symlinked /home/userid/projects/workspace. I have entered the pattern "/home/h0/userid" in all three exclude sections (files, file watcher and search). Now IntelliSense stopped working, since it doesn't found files under /home/h0/userid and for some reason it doesn't search /home/userid (it never did so, "Search: Follow Symlinks" is activated).
BTW: I had to restart VSC in order to activate the newly entered exclude patterns. If this behavior is intentional, it should be somehow documented.
@krzikalla Are you able to workaround the issue via opening /home/h0/userid? The problem is our extension is resolving all symlinks to their target but VS Code is not, and VS Code interprets the resolved path as being different. Using files.exclude or C_Cpp.files.exclude is not likely to do what you want if the path is part of your workspace.
The required restart sounds like it could be a bug -- you could file a new issue on that if you have more repro details.
The thing is, that the h0 in /home/h0/userid may change. I guess, it is rather a VSC issue. If you aggree, I'd file an issue there. In the end using any exclusions should not be necessary, if the handling is done correctly. Admittedly it is not that easy. E.g. in my case a resolved path has to be adapted to the workspace folder (which has a symlink inbetween).
I think it's a bug with our extension, so you could try filing a VS Code issue, but they may close it and say it's our bug or maybe they'd have some idea for a fix on their side or some suggested workaround. This VS Code issue may already cover the issue: https://github.com/microsoft/vscode/issues/34627
I thought it is a VS Code issue, since it also happens with "Find in Files", which (as far as I understand) is not related to the extension.
@krzikalla If you can repro the bug with our extension disabled then it would be a VS Code issue. It's possible that Find in Files could repro the issue because our extension is causing the "wrongly" named document to be opened.
Hmm, the issue seems to be complex. After disabling the extension no "wrongly" named documents(*) were found (I've also cleared the exclude settings and restarted). However, after reenabling the extension, "Find in Files" still didn't found any "wrongly" named documents. Intellisense however opened those "wrongly" named documents again causing doubly opened files. So maybe the issue is indeed on your side.
(*) A "wrongly" named document has the hard path (without the symlink of the workspace folder).