Document setup of rust-analyzer specifically for rustc hacking atop "popular" IDE/editors

[pnkfelix]

I took an informal poll at the last compiler triage meeting to get an idea of what editors/IDEs the current set of rustc developers use to hack on rustc.

The reason I asked the question was that I wanted to know which environments we should aim to document decently in terms of "how do I set up rust-analyzer here", and, if necessary, "how do I make rust-analyzer work well with rustc here"

The answers:

• vim: 6 (4 of whom already use rust-analyzer)
• VS Code: 5 (3 of whom already use rust-analyzer)
• emacs: 2
• Sublime Text: 1
• IntelliJ Rust: 1

I'm guessing there's no point in "integrating" rust-analyzer with IntelliJ Rust.

But the other four cases are worth documenting.

• VS Code is the primary target for rust-analyzer, and so documenting that should be trivial
  • (mostly, AFAICT, about how to properly open the rustc project so that the IDE knows where to look for the Cargo.toml.)
• vim is the most popular editor so I guess it should get the most attention
  • matklad did warn me ahead of time that it may be difficult to document since there are multiple lsp extensions available for it.
• I use emacs and I mess it up all the time so I will be happy to write down the concrete set up steps.
• We'll see about Sublime Text

[pnkfelix]

Ah, I had promised at that same meeting to do the aforementioned survey via email, since I was worried that relying on the meeting alone was going to leave out contributors. I'll set up that survey next before I make any prioritization decisions based on the data above.

(However, I feel pretty safe saying that we should, at minimum, document how to setup rust-analyzer/lsp integration with vim, vscode, and emacs.)

[spastorino]

https://github.com/prabirshrestha/vim-lsp seem to be one of the most popular ones. Maybe targeting just that one or two would suffice for vim?.

[mark-i-m]

I personally use neovim with coc.nvim + rust-analyzer.

[jyn514]

My ide experience with rustc has not been great. Setting any tool to run x.py check in the background completely breaks my build directory because x.py doesn't have build locks - cc @Mark-Simulacrum, maybe this is something that could be added? Until then though I'd be hesitant to recommend any extension that goes through cargo (notably RLS and rust_analyzer).

[mark-i-m]

I've never actually done that. I just run stock rust-analyzer without changing any settings at all, and it works fine.

[jyn514]

Stock rust-analyzer runs cargo check in the background AFAIK. Either that or there's something else breaking my build directory 👀

[mark-i-m]

Yep, that's my understanding as well, and yet somehow things just work... That said, I tend to mostly use rust-analyzer for completion and error messages; I don't use all of the extra IDE features, so perhaps there is something broken but I don't use it?

[jieyouxu]

Triage (in 2024): our setups have pretty much all converged on r-a, and editor setups on top of that are supported by ./x set $editor in bootstrap (e.g. helix, vim/neovim, emacs) and can have examples in src/etc/. RustRover (from Jetbrains) doesn't really handle the r-l/r repo structure because it's slightly cursed and it doesn't use r-a, but yeah.

There is now plenty of info on https://rustc-dev-guide.rust-lang.org/building/suggested.html#configuring-rust-analyzer-for-rustc, so closing as completed.