Rls: "File not found (c:\projects\rust\src\libpanic_unwind\lib.rs)" in VSCode

[freedaun]

I get this error in VSCode after installing RLS.

Should be easy to solve (if RLS is the source of the problem) as this path does NOT exist on my machine (Windows).Seems like it confuses the rust-src folder.

Paste the error in Google to see more occurrences.

Newbie here.

PS: "Go to definition" in VSCode also doesn't work, seems related. Single stepping does (seem to) work and I have a pane with variables.
PS: I did cargo install cargo-clone only to observe that after launching another shell the clone command was gone. Did it forget rust-src also? Probably not, because rustup component add rust-src --toolchain nightly says all is fine.

[freedaun]

For reference:

> rustc --print sysroot
C:\Users\user.rustup\toolchains\stable-x86_64-pc-windows-msvc

[freedaun]

A maybe related error occurs after "Find implementations":

"find implementations failed: Error: Connection got disposed."

My "Output" pane has this:

[Info - 14:32:23] Connection to server got closed. Server will restart.

Doesn't say which server..

[freedaun]

There are similar errors after F11 (which should put the window full screen...):

Unable to open 'once.rs': File not found (c:\projects\rustsrclibstd\sync\once.rs).
Unable to open 'once.rs': File not found (c:\projects\rustsrclibstd\sync\atomic.rs).

I have no idea what these files are ;)

[freedaun]

Bump.
Because this path does not exist on my machine. Should be easy to find.

[jonasbb]

@freedaun I think you are mixing some things here. So let's see if I get them right.

First, there is a long outstanding bug that jumping to stdlib does not work (e.g., https://github.com/rust-lang-nursery/rls/issues/477). Currently there is no solution for this except creating the directory on your filesystem/creating a link.

The "Find implementation" related error: RLS is not fully stable and can crash. It might be restarted or you might need to reload VS Code to get it back working.

Lastly, from your description it sounds like you are in the debugging mode of VS Code. In this case F11 does not put it into full screen but performs "Step Into". Debugging is not part of RLS as such the error is not caused by RLS. How to fix it depends on the debugging extension you use. For example the LLDB Debugger extension has a source path remapping function https://github.com/vadimcn/vscode-lldb/blob/master/MANUAL.md#source-path-remapping.

[freedaun]

@jonasbb Thanks. Yeah, I am sure to mix things up :) As the functionality I get from RLS was severely compromised, I thought this was relevant.

The functionality I get from RLS is best described as "nothing". Nothing works, except notifications (like "Loading..." and "RLS analysis working") and errors.

But this is on Windows and usually a lot goes wrong on Windows (like depending on a 5GB MS download puzzle). I am glad to finally have something that single steps.

[freedaun]

The functionality I get from RLS is best described as "nothing". Nothing works, except notifications (like "Loading..." and "RLS analysis working") and errors.

Today, suddenly, symbol completion is working. I don't know if a restart did the trick.

But it is only partially working: "Goto definition and family" still do not work.

[whoif]

Just want to add that, for any user that use C/C++ debugger in VS Code (as I do), there is also a way to configure the mapping from the wrong source path to the correct one, so as to fix the problem mentioned in the title of this issue.
In launch.json file, modify it as this

"configurations": [
{
......
"sourceFileMap": {
"c:/projects/rust/src": "PATH/TO/YOUR/SOURCE/DIR"
}
}
]

Hope this helps for some.

[hlavaatch]

What you want today is install rust-src component of the toolchain

rustup component add rust-src

and then put in launch.json:

            "sourceFileMap": {
                "c:/projects/rust/src": "${env:USERPROFILE}\\.multirust\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\src\\rust\\src"
            },

maybe also

"program": "${workspaceFolder}/target/debug/${workspaceFolderBasename}.exe",
"symbolSearchPath": "https://msdl.microsoft.com/download/symbols"

[jcageman]

I am now getting the following issue on windows 10:
Unable to open 'lib.rs': Unable to read file (Error: File not found (c:\rustc\3c235d5600393dfe6c36eeed34042efad8d4f26e\src\libpanic_unwind\lib.rs)).

Apparently the fix is not that obvious in terms of the sourceFileMap fix, therefore here the my specs for future reference:

...
"type": "cppvsdbg",
"sourceFileMap": {
    "/rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e": "${env:USERPROFILE}\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\src\\rust",
    "d:/agent/_work/4/s/src/vctools/crt/vcstartup/src/startup": "${env:VS140COMNTOOLS}\\..\\..\\VC\\crt\\src\\vcruntime",
    "d:/agent/_work/4/s/src/vctools/crt/vcruntime/src/eh": "${env:VS140COMNTOOLS}\\..\\..\\VC\\crt\\src\\vcruntime"
},
"symbolSearchPath": "https://msdl.microsoft.com/download/symbols"

That fixes loading certain symbols and also errors:
Unable to open 'exe_common.inl': File not found (d:/agent/_work/4/s/src/vctools/crt/vcstartup/src/startup/exe_common.inl).

Unable to open 'throw.cpp': File not found d:/agent/_work/4/s/src/vctools/crt/vcruntime/src/eh/throw.cpp

[Dan-True]

I have a similar situation which I think might be the same underlying issue. I get this after debugging (debugging works fine, but the error is thrown when the program terminates):

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

I tried something akin to the above fix from jcageman, adding this to my launch.json:

sourceFileMap": {
                "/rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c": "${env:USERPROFILE}\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\src\\rust",
                "d:/agent/_work/4/s/src/vctools/crt/vcstartup/src/startup": "${env:VS140COMNTOOLS}\\..\\..\\VC\\crt\\src\\vcruntime",
                "d:/agent/_work/4/s/src/vctools/crt/vcruntime/src/eh": "${env:VS140COMNTOOLS}\\..\\..\\VC\\crt\\src\\vcruntime"
            },
            "symbolSearchPath": "https://msdl.microsoft.com/download/symbols

But this only lead debugging to stall at the beginning with the following message:

Resolving variables in sourceFileMap...
    Replacing targetPath '${env:USERPROFILE}\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust' with 'C:\Users\dan-t\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust'.

Which is wher eI'm stuck at now. As I said, I can debug - it's just a nuisance.

[backtolife2021]

The sourceFileMap property is now not allowed.

My mitigation method is to create a Symbolic link.

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