Not sure if this is the place to report this. The rust-src and rust-analysis components seem to be out of sync on Rust 1.31.0 stable: The _go-to-definition_ on std items tries to open a file with a slightly different location:
For example, Go to definition for HashMap tries to open
~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/libstd/collections/hash/map.rs
(note the missing src directory between rust and libstd) while the file is located at
~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/collections/hash/map.rs
I have the problem both on Linux and macOS (while running rls through vim if that makes any difference). Installed using rustup component add rls rust-analysis rust-src. Even after I tried to rustup uninstall stable and reinstall it the problem persists.
Disappointing that this "src" issue managed to fall into the stable release. You may be right that out of date dependencies on the stable channel are to blame.
As a workaround switch to beta or nightly.
Related: https://github.com/rust-lang/rust/pull/53586, #1140
@nrc goto-definition is not fixed in stable
I have the problem both on Linux and macOS
Can confirm same on Windows (just to rule out platform-specific issue).
Hmm, so both #1138 and #1147 made it to stable, which they probably shouldn't have done, however, the latter undoes the former, so I'm not sure what is going on. On Rust, https://github.com/rust-lang/rust/pull/56194 should have fixed the breakage done by https://github.com/rust-lang/rust/pull/53586 but I don't think either of them made it to master.
We're using 0.16.10 of rls-analysis. We probably want a fork, that has the most recent commits, but with d5d2f98d6f7668e2b6139c6cd93a8d20e28c396b reverted.
@nrc I pushed rls-analysis branch and rls branch using that at (based on what's in 1.31 rust/stable now):
https://github.com/rust-dev-tools/rls-analysis/tree/1.31-stable-src-prefix-fix
https://github.com/rust-lang/rls/tree/1.31-stable-src-prefix-fix
However, rls now points to a branch at rust-dev-tools/ team, which I'm not sure we accept in-tree.
Should we vendor the rls-analysis fork inside the Rust tree on stable channel?
I'm seeing the same issue on emacs with lsp-rust.
When trying to go to definition on, for example, String::from, emacs (LSP) answers:
Cannot read ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/libcore/convert.rs
The real location is:
~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/convert.rs
Running on stable-x86_64-unknown-linux-gnu unchanged - rustc 1.31.0 (abe02cefd 2018-12-04)
This will be fixed in Rust 1.31.1, scheduled to be released on Thursday 20th.
@rekka @RReverser @petergardfjall can you check if this is fixed in Rust 1.31.1? You can download the pre-release with:
RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable
@pietroalbini Seems to work now with no problems on macOS and Linux for me. Thanks for the fix! And as a nice bonus, RLS now respects the target directory in .cargo/config!
It appears to be working on my end as well!
Yay finally.
Working on Windows using Rust 1.31.1! Thanks!
Is this issue resolved for the target x86_64-pc-windows-msvc?
It is working for i686-pc-windows-msvc, but not x86_64-pc-windows-msvc in my appveyor job.
Just wondering.
Running Install scripts
curl -sSf -o rustup-init.exe https://win.rustup.rs/
rustup-init.exe -y --default-host %TARGET%
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
info: latest update on 2019-01-17, rust version 1.32.0 (9fda7c223 2019-01-16)
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: installing component 'rust-docs'
info: default toolchain set to 'stable'
stable installed - rustc 1.32.0 (9fda7c223 2019-01-16)
Most helpful comment
This will be fixed in Rust 1.31.1, scheduled to be released on Thursday 20th.