search

microsoft / vscode-cpptools

Official repository for the Microsoft C/C++ extension for VS Code.
Other
5.51k stars 1.55k forks source link

Go to declaration always shows 2 files, relative and absolute paths #3288

Open idanemergi opened 5 years ago

idanemergi commented 5 years ago

Type: LanguageService

Describe the bug

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:

  1. Open file using ctrl+p
  2. 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: image

idanemergi commented 5 years ago

anyone? this is really frustrating...

sean-mcmanus commented 5 years ago

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?

bobbrow commented 5 years ago

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 ".".

idanemergi commented 5 years ago

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.

idanemergi commented 5 years ago

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.

sean-mcmanus commented 5 years ago

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.

idanemergi commented 5 years ago

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?

sean-mcmanus commented 5 years ago

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.

yatian-liu commented 5 years ago

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.

dev-guy commented 4 years ago

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.

jamietre commented 4 years ago

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.

sean-mcmanus commented 4 years ago

@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.

farqq commented 4 years ago

Is there any solution now?

sean-mcmanus commented 4 years ago

@farqq Not yet.

occia commented 4 years ago

Is there any plan to fix this?

sean-mcmanus commented 4 years ago

@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 commented 4 years ago

Is there any solution now?

sean-mcmanus commented 4 years ago

@Victsz There is no solution yet. If this becomes fixed, we'll most likely mark this issue as "Fixed (pending release)" and close it.

o-u-p commented 3 years ago

mark

jinbeomdev commented 3 years ago

Plz...Solve this problems on linux

vc commented 3 years ago

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.

krzikalla commented 3 years ago

I've also encountered this bug more than once. Client runs on Windows, server runs on Linux. Some observations:

  1. It has nothing to do with sym links - I don't have any.
  2. Pressing F12 opens the file with absolute path - even if the requested location is in the active file.
  3. 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 ...").
  4. 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"?)
  5. 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.
sean-mcmanus commented 3 years ago

@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.

krzikalla commented 3 years ago

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.

sean-mcmanus commented 3 years ago

@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.

krzikalla commented 3 years ago

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).

sean-mcmanus commented 3 years ago

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

krzikalla commented 3 years ago

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.

sean-mcmanus commented 3 years ago

@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.

krzikalla commented 3 years ago

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).

wwm0609 commented 3 years ago
  1. Pressing F12 opens the file with absolute path - even if the requested location is in the active file.

I can produce this issue with either clangd or cpp-tools enabled. It seems to be the language server's fault even through I'm not sure whether cpptools uses clangd under the hood. FYI, see https://github.com/clangd/clangd/issues/544

DanMacDonald commented 2 years ago

So I was having a problem with intellisense not working for code files in a symlinked directory. The base path for the directory had a parent directory whose name had a space in it, when I removed the space from the path VSCode was able to do all its syntax/reference count checking for files in the symlinked directory.

Note: The one exception here, on the command pallet, you can look up classes in the symlinked directory by type, but trying to look them up by filename fails. 🤷‍♂️

wwm0609 commented 2 years ago

For anyone who might be intertested, there is a workround: If you pc is running unix like systems, then instead of using symlinks, you might want to switch to "bind mount", e.g.

$ mkdir ${the_link_dir_you_want} # If not exists yet
$ sudo mount --bind ${source_code_dir} ${the_link_dir_you_want}
$ code ${the_link_dir_you_want} # Enjoy coding
starball5 commented 1 year ago

Related(?): #4573.

Related on Stack Overflow: VS Code Error Squiggles do not work if the project dir is a symlink.

starball5 commented 9 months ago

Someone on Reddit is reporting (here) that when they open a file from the Explorer that is under the workspace folder (and when the workspace folder is under the user home directory), it has a path with ~/... in it, but then when navigating to that file with Go To Definition, it opens in a separate editor tab, with a path starting with /home/... instead. Is that related to this issue ticket or to #8823, or should a new issue ticket be raised?

cellularmitosis commented 3 months ago

This appears to still be a problem. I recently created a ~/include and populated it with symlinks to the .h files for the Raspberry Pi Pico pico-sdk, and intellisense can't seem to find anything (e.g. #include "hardware/pio.h" has red squiggles underneath.

I then replaced all of the symlinks with copies of the files and now intellisense works.

While going down this rabbit hole, I discovered to my dismay that grep also has goofy behavior with regard to symlinks:

    -S      If -R is specified, all symbolic links are followed.  The default is not to follow symbolic links.
mrlifetime commented 3 months ago

In our org all home directories of developers are symlinked. This really hurts "go to definition/declaration" (are they supposed to do the same thing?) feature because the first thing it does is open the same file with the absolute path. Better symlink support would really help productivity, I am surprised something so basic isn't supported already.

MissiontoMars commented 1 month ago

python development encountered a similar problem, for example, the code root directory is /home/me/repo, go to definition jump to the absolute path. I created a soft link to the repo (ln -s repo_link repo) and opened the repo_link instead of the repo with vscode, which unexpectedly solved the problem, although I don't know why.