-
Notifications
You must be signed in to change notification settings - Fork 29.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open file links from console or compile output #98593
Comments
(Experimental duplicate detection) |
btw, thanks vscodebot for suggesting this possible duplicate. I'm not sure however if this is indeed a duplicate or a different issue. Especially here I'm working with VSCode on Windows, but using Remote Development on a Linux machine. So for the Windows VSCode the two file name variants might not be that easy to interpret as "equal" - but perhaps they can be interpreted as "equal" by the Remove Development extension? |
btw, I just realized that also "C++: Switch Header/Source" has this issue, it opens the file with absolute path, i.e. outside of the VSCode workspace. |
I cannot reproduce this, either with relative or absolute links in the terminal. Could you first try the new terminal links using this setting:
If it still happens can you take a screenshot of the following and post here:
|
Hi Tyriar! As I explained in my second comment, I'm using Remote Development. When I worked natively on Linux the issue didn't occur, so I assume that it's caused by using Remote Development with VS Code on Windows and the source code residing on Linux. Let me build a small example outside of my productive development workspace to reproduce the issue, so I can safely post screenshots and further information here. Thanks, |
Hi! |
I cannot easily reproduce the build error issue with this dummy project. We're using cmake with a custom wrapper around. This cannot be setup so easily for my dummy project. When I simply execute gcc with my sources, e.g. gcc struct.cpp, the compiler output only contains relative paths, and opening these links doesn't work. With our cmake project we get error messages with absolute paths. But since VS Code uses relative paths for files from the workspace, opening these links with absolute paths causes this issue. |
@bpasero maybe duplicate of #12448? See #98593 (comment) that struct.h is showing up as 2 tabs |
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/ |
Hmm, the latest insider build doesn't work for me, remote connection fails: Install and start server if needed |
@hensz what remote is that, WSL? |
No, it's a native Linux I connect to via ssh - i.e. a different machine. |
@roblourens @Tyriar do you know anything about |
Can you make sure that you have the latest version of the SSH extension installed? Haven't used that API in awhile. |
Hi! But besides that the initial problem is still effective: When running the command Switch Header/Source the respective file is opened "outside of workspace", same for clicking links in compile errors. Just to clarify: With our compilation setup (cmake with gcc) we get compile errors with absolute paths. In my example with only using gcc directly the compile errros contain relative paths, and here clicking on the file links doesn't work at all. |
@hensz to clarify this only happens in a remote connection, not locally right? And you are connecting to a SSH that produces output with file links that you click on from the output window? Or is that the terminal? |
Hi! Perhaps this is related with how we've set up our project. I've simply opened the folder in VS Code, but also I set the compileCommands setting to a compile_commands.json generated from our cmake configuration. Perhaps this configuration is behaving "strange". To validate if the compileCommands is causing this issue, can you tell me what information Switch Header/Source is using, and how file paths are interpreted in compile errors (wrt. relative or absolute paths)? |
Sorry, I do not follow. Can you copy a path from the explorer and then copy a path from the editor to compare it and paste the results here? |
In my example above the workspace is located in this folder: In this folder I have two files, struct.h and struct.cpp. When I open these files from the Explorer in VS Code, they are opened with relative paths, i.e. ./struct.h and ./struct.cpp respectively. When I open the header for the cpp file with Switch Header/Source the header ist opened with absolute path, i.e. /data/user/workspace/test/struct.h. As you can see in the screenshot I posted 3 days ago this file is now opened twice. So to me it seems that the command Switch Header/Source determines the respective other file with some heuristic or from some information from the workspace (e.g. from compile_commands.json) for some reason with absolute path, while normally files from the workspace are considered with relative paths (relative to the workspace root). Also when I get a compile error, the files are printed with absolute paths, e.g. /data/usr/workspace/test/struct.cpp - and when I click this path, this is considered as a different file than the one from the workspace, since VS Code "knows" this one as ./struct.cpp. |
VSCode does not support this, so you are using an extension for it? Then please report it against the extension, I cannot control what the extension is doing. Can you PLEASE follow the steps and:
Paste both here. |
Hi! Now that was a real help! I totally forgot that I'm using a symbolic link for my workspace. The "physical" folder /data/usr/workspace is represented by a link /workspace. And the workspace I opened in VS Code is exactly this link: /workspace/test. So both paths from explorer and the file opened from the explorer is using the symlink: I think this is the root cause of the issue. Let me check what happens when I open the workspace with the "physical" path... Yes, now the path is always the same, the "correct" one so that VS Code considers the file as part of the workspace. So from my perspective we could either close this issue as "PEBCAK", or we could try to solve the different handling of pathswith symbolic links. It's definitely possible to determine that a path contains a symbolic link and resolve this link - this is exactly what "Switch Header/Source" and our build mechanism does, so also VS Code could do that. But fixing this is definitely not a high priority for me :-) Thanks a lot for the help to identify the actual root cause! |
Hi!
When I either do a compilation in the integrated terminal or with a build task and I click on a file "link" for an error or a warning, the file is opened differently than when I open it from the Explorer pane.
Files opened from the Explorer pane are displayed with a relative file path (relative to the workspace root I assume). However, since the file names in compiler output have absolute paths (at least in my case, not sure of this can be changed somehow) the file is also opened with absolute file path. My assumption is that now VSCode "thinks" that this is a different file than the one opened from Explorer. Therefore the file is opened twice, which causes quite some confusion, especially both variants can be edited simultaneously, eventually resulting in conflicts during saving the second one.
Also the search is affected: If a file was opened from the compile output each search results in that file are displayed twice, once in the regular list of results, and once under "Other files".
Steps to Reproduce:
The text was updated successfully, but these errors were encountered: