Tracking issue fo RFC2912, transition to rust-analyzer as our official LSP

[matklad]

Issues blocking providing rust-analyzer as an alternative

• rust-analyzer should mostly conform to LSP protocol
  • specifically replace adHoc "rust-analyzer.applySourceChange" with less adHoc SnippetTextEdit
• rust-analyzer should be packaged with rustup
• rust-lang.rust extension should work with both rust-analyzer and rls
  • all the code from editors/code in this repo should be moved to https://github.com/rust-lang/rls-vscode

Issues blocking switching to rust-analyzer as the main implementation

• rust-analyzer should fully conform to LSP protocol

Issues under discussion

• on the fly checking
• RAM usage
• startup time

[eminence]

Could someone briefly describe how RLS does on-the-fly checking? I know that rust-analyzer on-the-fly checking will be implemented in its own way, but knowing how RLS does it I think could be some useful background knowledge for this thread.

[bjorn3]

RLS acts as a custom rustc driver and uses an internal compiler api (FileLoader) to provide sources directly to the parser without reading from the disk. The main problem with this, it that it is tied to a specific rustc version.

[Xanewok]

We can somewhat tick the blocking issue box:

rust-lang.rust extension should work with both rust-analyzer and rls

Implementation

Also posted it in the RFC thread: rust-lang/rfcs#2912 (comment)

It doesn't provide exact feature parity since it doesn't work yet with messages such as rust-analyzer.applySourceChange and other custom extensions that are not LSP-proposed.

[matklad]

#4494 implements code action snippet capability.

[matklad]

I've transitioned all code actions to use progressive enhancement, so code actions in next release should just work with any any editor which implements codeActionLiteralSupport. We do not implement command-based actions, as those require custom client-side plumbing or round-about workspace/applyEdit. This is conforming to the protocol (we just don't emit code actions without codeActionLiteralSupport) and i think should be fine in practice: if client supports workspace/applyEdit, it shouldnt't be problematic to support suppling edit directly with code-actions. I'll mark some comments in this thread as resolved.

I've also started documenting all our protocol extensions in this document.

At this point, although we are not fully confirming to the protocol yet, I believe we've solved all major practical conformance issues.

[hannobraun]

I've made the change and released versions 0.8.3 and 0.7.1. Please let me know if it helps.

[matklad]

That worked, thanks @hannobraun !

[matklad]

Current status:

15:04:42|~/projects/rust-analyzer/editors/code|master✓
λ rustup component add --toolchain nightly rust-analyzer-preview
info: component 'rust-analyzer-preview' for target 'x86_64-unknown-linux-gnu' is up to date

15:04:46|~/projects/rust-analyzer/editors/code|master✓
λ rustup run nightly rust-analyzer --version
rust-analyzer f5a4a4b

[tesuji]

Also one could create a symlink for convenient reasons:

ln -s $(rustup which rust-analyzer ) ~/.local/bin/rust-analyzer

[lnicola]

Should rustup have a rust-analyzer shim?

[matklad]

@lnicola I think we need to add something else for that.

I've opened rust-lang/vscode-rust#812 for the last bit we need to fix before we can start the "feedback govering" phase properly.

[llucax]

Hi, on major blocker for me to adopting rust-analyzer (as a CoC plugin in (neo)vim) is the inability to update errors on the fly. This is already listed here but I didn't see any links to specific issues. Searching I found #6591, which looks like it is requesting the same. If this is correct, maybe it would be useful to link it in the TODO item in the issue description, so other people that want to monitor particular items on the TODO list can subscribe to the specific issues.

[matklad]

Note that the real blocker today is non-technical. We need to move rust-analyzer over to rust-lang project before it can be made official. We are slowly but steadily doing that with the rust-lang core team.

[Xanewok]

Since https://blog.rust-lang.org/2022/02/21/rust-analyzer-joins-rust-org.html has been announced and it seems that Rust Analyzer has joined the Rust org (does it mean that the repository will move?), I'd gladly move or replace the code for the current VSCode extension with the Rust Analyzer VSCode extension (maybe with an added option to run RLS if already installed by rustup) to quickly move things forward.

To give some more context from my side: I've obviously dropped the ball with the migration tracked at rust-lang/vscode-rust#812. I was and am still struggling with mental health issues and it became apparent that I cannot keep up with my existing open source obligations (at least I viewed them as such) and couldn't maintain the outlined pace of work nor even communicate that properly. I'm really sorry for that.

I'm very happy that the Rust IDE story is getting better and better with every week and I'll happily coordinate with adding new maintainers to the official Rust VSCode extension and with any work required to make the switch (should I CC any specific RA team?). Thanks for all your hard work on the Rust Analyzer and other IDE-related bits!

[digitarald]

I work on VS Code and a few team members also noted how much better Rust editing is with rust-analyzer. I dug deeper as VS Code had a built-in recommendation for the rust-lang extension and found this issue.

As one fix the upcoming VS Code 1.66 will start recommending rust-analyzer. Until the extensions are unified this seems the best experience for users. Feel free to contact me if you need help with the transitioning in VS Code or Marketplace.

[Veykril]

As rust-analyzer has transitioned to the rust-lang org we can close this issue 🎉

There was a slight change of plans regarding the VSCode extensions, as instead of merging the two VSCode extensions as described in rust-lang/vscode-rust#812, https://github.com/rust-lang/vscode-rust is now being deprecated in favor of the rust-analyzer vscode extension which also has now moved publisher to rust-lang on the marketplace. Likewise RLS is being sunset rust-lang/rust#100863 now, although that was outlined in the RFC anyways.