goto definition outside crate

[dvic]

Is the goto definition feature supposed to work also outside the current crate? E.g., when you click on a method from an external crate, you cannot use goto definition from there. However, if I open that external crate folder and make RLS index it (by opening a .rs file), then it works. Is this the way it's supposed to work or is there something wrong with my configuration? Thanks!

[kavu]

@dvic can you try "rust-client.channel": "nightly" in your VS Code settings? It worked for me — now I can go to definitions of std library members, along with external crates. Obviously, I am on nightly version of Rust.

[dvic]

@kavu thanks for the tip, but it did not work for me. I'm also using nightly. Are you on MacOS?

[kavu]

@dvic yeah. Just checked it on my office Mac. Still works, but I had to reopen my VS Code project to force RLS to rebuild / update the project info. After that I could hover over functions from external crates and even Cmd-click them to jump to their source. Maybe you were asking about something else and I misunderstood you?..

[dvic]

@kavu No no it's exactly what you are describing that I'm trying to achieve. I tried restarting visual code, restarting RLS, still doesn't work. So I guess there is something wrong with my environment/setup? Do you know how I can debug the visual code extension (e.g., enable logging?)

[dvic]

Found it here: https://github.com/rust-lang-nursery/rls/blob/master/debugging.md#logging

I don't see anything in the logs that could explain the behavior. It simple stops after I cmd click and jump to a source file outside my crate.

[dvic]

Update from rust-lang/atom-ide-rust#96: it seems that the Atom plugin filters project files before sending them out to the RLS. Does Visual Code also do this? That could explain the issue.

[JeanMertz]

I have the exact same issue. I tried using cargo-vendor to have my dependencies be in the same directory as the project, and after restarting vscode the first "click through" indeed goes inside the vendor directory, but even then when I click on the next object, it complaints "no definition found", even though I can see the file that has the definition right there in the side bar, inside my project, next to the file I'm currently in.

I also tried "rust-client.channel": "nightly", but that too doesn't work.

I'm trying this on macOS 10.13.6, vscode 1.27.0-insiders, vscode-rls 0.4.9 rustc 1.30.0-nightly (d767ee116 2018-08-15) rls-preview 0.130.5-nightly (9e4d8d5 2018-08-10)

[JeanMertz]

By the way, setting "rust.goto_def_racer_fallback": true as described here makes this work for most of the cases, but not all of them, and obviously without using RLS.

[kbarros]

Ran into this issue as well. Bummer.

[kbarros]

Same as this issue?

[DanielJoyce]

If RLS is still this broken, maybe they should just go back and use racer then. Ugh.

[DanielJoyce]

Still not working for me. Can not go to definitions for external projects...

[dvic]

Same here, still not working.. It still only works when you add the crate folder to the workspace.

[prasannavl]

Same here. I think it has to do with the rls itself rather than vscode plugin. Had stayed on some Nov/Dec 2018 nightly where everything from the https://rust-lang.github.io/rustup-components-history/ actually built, for a long time now. Go-to-def worked great across crates and stdlib.

Just upgraded to to another March variant last week that built most of the components I need and it no longer works outside of the crate.

[Xanewok]

racer_autocompletion is enabled by default, which enables the gotodef support outside of the given project as detected by RLS. I know we can do a lot better know but this needs more architectural changes in the RLS itself.

[zhiqiangxu]

Still not work for external crates...

[thxjia]

use matklad.rust-analyzer, work well