Skip to content
This repository has been archived by the owner on Dec 29, 2022. It is now read-only.

Unable to open 'rt.rs': Unable to read file in Visual Studio Code #1542

Open
Dan-True opened this issue Aug 13, 2019 · 9 comments
Open

Unable to open 'rt.rs': Unable to read file in Visual Studio Code #1542

Dan-True opened this issue Aug 13, 2019 · 9 comments

Comments

@Dan-True
Copy link

Hi.

I'm new to Rust and I followed this blogpost to setup coding in VS Code:
https://www.twelve21.io/getting-started-with-rust-on-windows-and-visual-studio-code/

I can now build and run in command line and build and debug VS code. Good stuff.

However, when using the debugger after the program terminates I get this error:

Unable to open 'rt.rs': Unable to read file (Error: File not found (c:\rustc\a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\src\libstd\rt.rs)).

Which is an invalid path. C:\rustc does not exist on my drive.

I can find other issues with unreadable files, but none of the resolutions did anything. I've tried removing rust, rustup, VS Code and all extensions several times to no avail.

From what I can see rt.rs provides an API that has something to do with the heap and for running code after the main thread finishes. Is it attempting to do some cleanup after the debug session ends, perhaps?

It's not blocking: I can build, test and debug. But it's quite annoying to get this message. Anyone else having this problem?

@ferhat-aram
Copy link

Yeah, i got the same issues. Tried even the solutions as described here: #472 (comment).

Still didn't fix it.

@I-Want-ToBelieve
Copy link

You need to make sure you have RLS installed.

You need to make sure the directory: c:\rustc\a53f9df32fbb0b5f4382caaad8f1a46f36ea887c exists, if the directory does not exist you need to create it manually

The last step is:
In the CMD terminal running with Administrator privileges:

mklink /d c:\rustc\a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\src c:\Scoop\persist\rustup\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\src

Please note that my rust installation directory is not the same as you.
You need to change it(c:\Scoop\persist\rustup.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\src) to your own path.

@Dan-True
Copy link
Author

Dan-True commented Sep 3, 2019

You need to make sure you have RLS installed.

You need to make sure the directory: c:\rustc\a53f9df32fbb0b5f4382caaad8f1a46f36ea887c exists, if the directory does not exist you need to create it manually

The last step is:
In the CMD terminal running with Administrator privileges:

mklink /d c:\rustc\a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\src c:\Scoop\persist\rustup\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\src

Please note that my rust installation directory is not the same as you.
You need to change it(c:\Scoop\persist\rustup.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\src) to your own path.

Thank you. This seems to solve the problem. No idea why the install scripts didn't do this by themselves.

  • Dan

@Dan-True Dan-True closed this as completed Sep 3, 2019
@joshhansen
Copy link

@Dan-True Seems to me like this issue is still open if this is the best solution we have. More of a stopgap.

Isn't the real issue that RLS thinks the sources are somewhere that they aren't? Can't we point it in the right direction somehow (other than using the filesystem)?

@Dan-True
Copy link
Author

@Dan-True Seems to me like this issue is still open if this is the best solution we have. More of a stopgap.

Isn't the real issue that RLS thinks the sources are somewhere that they aren't? Can't we point it in the right direction somehow (other than using the filesystem)?

Well, if this is a recurring problem, then yeah we have a problem still. But it may just have been a fluke on me and tupisks systems I guess.

@joshhansen
Copy link

I've just experienced it myself, and I've seen other reports of it online, so it appears to be a continuing issue.

@Dan-True
Copy link
Author

Reopening then.

@Dan-True Dan-True reopened this Sep 26, 2019
@rlabrecque
Copy link

rlabrecque commented Nov 9, 2019

Hey everyone, yeah this does seem to be an issue still.

In VSCode on Windows with the VS toolchain (``"type": "cppvsdbg",`) you can work around this by adding a sourceFileMap to your launch.json like so:

{
    "version": "0.2.0",
    "configurations": [
            "name": "Debug",
            "type": "cppvsdbg",
            "request": "launch",
            "program": "${workspaceFolder}/target/debug/YOUR_EXECUTABLE.exe",
            "args": [],
            "stopAtEntry": false,
            "externalConsole": false,
            "preLaunchTask": "cargo build",
            "type": "cppvsdbg",
            "sourceFileMap": {
                "/rustc/4560ea788cb760f0a34127156c78e2552949f734": "${env:HOME}${env:USERPROFILE}\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\src\\rust"
            }
        }
    ]
}

If you're using gdb via "type": "cppdbg", then same thing but use this instead of sourceFileMap:

            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "description": "Required for the below to work since this gets run before the symbols get loaded. 'Make breakpoint pending on future shared library load?'",
                    "text": "set breakpoint pending on",
                    "ignoreFailures": true
                },
                {
                    "description": "Break on any exception",
                    "text": "break rust_panic",
                    "ignoreFailures": true
                },
                {
                    "description": "Enable viewing of the std source code during debugging",
                    "text": "set substitute-path /rustc/4560ea788cb760f0a34127156c78e2552949f734 /home/username/.rustup/toolchains/beta-x86_64-unknown-linux-gnu/lib/rustlib/src/rust",
                    "ignoreFailures": true
                }
            ],

Replace 4560ea788cb760f0a34127156c78e2552949f734 with the hash which you receive when you try to navigate to a rust source file.

I'm not sure if this is specifically an rls issue, seems to be a more general rustc issue?

@rlipscombe
Copy link

That last set substitute-path needs a space in it, and VS Code allows environment variables. I got it working with:

                {
                    "description": "Enable viewing of the std source code during debugging",
                    "text": "set substitute-path /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8 ${env:HOME}/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/",
                    "ignoreFailures": true
                }

I also found this link: https://jason-williams.co.uk/debugging-rust-in-vscode, which was useful.

I couldn't find a consistent way to figure out the hash before the debugger complains.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants