rls icon indicating copy to clipboard operation
rls copied to clipboard

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

Open Dan-True opened this issue 4 years ago • 9 comments

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?

Dan-True avatar Aug 13 '19 19:08 Dan-True

Yeah, i got the same issues. Tried even the solutions as described here: https://github.com/rust-lang/rls/issues/472#issuecomment-369513199.

Still didn't fix it.

ferhat-aram avatar Aug 25 '19 13:08 ferhat-aram

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.

I-Want-ToBelieve avatar Sep 02 '19 07:09 I-Want-ToBelieve

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 avatar Sep 03 '19 20:09 Dan-True

@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)?

joshhansen avatar Sep 25 '19 00:09 joshhansen

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

Dan-True avatar Sep 25 '19 09:09 Dan-True

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

joshhansen avatar Sep 25 '19 23:09 joshhansen

Reopening then.

Dan-True avatar Sep 26 '19 06:09 Dan-True

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?

rlabrecque avatar Nov 09 '19 00:11 rlabrecque

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.

rlipscombe avatar Feb 20 '20 19:02 rlipscombe