Use RustLSP library.

[bruno-medeiros]

A more extensive and principled way to handle the LSP protocol. Adds
interface support for all LSP requests.

Fixes:

• 'completionItem/resolve' should return CompletionItem not a vector
• Concurrent handling of requests. Requests must be handled in order,
  otherwise, for example, text document changes could be applied out of
  order. Only read-only requests can conceptually be executed in parallel
  (since that would have the same result as if they were processed in
  order). See here for more info:
  Clarify that the current protocol requires that requests and notification are processed in order microsoft/language-server-protocol#12

TODO for RustLSP:

• Cancel support
• Support sending requests to client from server
  (only notifications can be sent currently). This is required for one LSP
  request: 'window/showMessageRequest'.
• Perhaps integrate with https://github.com/ethcore/jsonrpc-core and
  share part of the JSON-RPC implementation?

[nrc]

I could probably find answers by reading the code, but there is a lot of it, so before I start:

• Is this an alternative to Use languageserver-types crate #79 or does it sit on top of that? (I.e., should I still be reading Use languageserver-types crate #79, or just this PR?)
• Is this WIP or ready to go now?
• Could you give an intuition for what is handled in the RLS and what is in each upstream crate?

Thanks!

[bruno-medeiros]

It sits on top of #79 . ATM, only the last commit here is unique to this PR. So #79 is still required.

Is this WIP or ready to go now?

It passes the rls and rustlsp tests, but they are pretty basic, only smoke testing. I haven't had the chance to test it properly with VSCode itself, haven't set that up yet. Will do that Monday or Tuesday hopefully. I haven't even tried the rls in action yet, at all 😅

But in terms of implementation, barring any bugs, it should be ready to go. There are those two TODO items mentioned above that are needed for full LSP support, however it's not something RLS is using at the moment. In other words the LSP functionality is not 100% complete but is already a superset or the LSP functionality that RLS currrently has.

Could you give an intuition for what is handled in the RLS and what is in each upstream crate?

I'm not sure what you mean, could you clarify?

[bruno-medeiros]

I've rebased this PR on top of newest rls.

Also, now using a more recent version of RustLSP that has added support for sending requests to client from server (required for LSP request: 'window/showMessageRequest'). (It's using new futures crate BTW 😃)

There are likely to be some minor API tweaks/refactors I wanna do, so you might want to hold off on reviewing for now (unless you're eager 😄 )

[nrc]

Thanks for rebasing!

So, I still don't have a good intuition for what the RustLSP crate does. Could you try and define it for me please? I don't see the abstract division of responsibilities here. At first I thought it was just a Rust-ifcation of the protocol (i.e., a type-safe view of the data), but it seems to be doing more than that. But the RLS still looks like it is doing a lot of the protocol handling 'server' stuff.

Basically, I'm unsure of what the value proposition of RustLSP is, and how to decide for any task, whether that task should be done by the RLS or RustLSP.

[bruno-medeiros]

RustLSP is a library for working with LSP, in Rust, but not necessarily targeting the Rust language. It is meant to be independent of the language that the server analyses. So if I wanted to write in Rust a language server for some other language, the common code bit between RLS and that other LS, would be RustLSP. I guess the name can be confusing, but couldn't think of a better one.

The analogue of RustLSP for say, Java, is LSP4J (note, to avoid confusion, LSP4J is not tied to the Eclipse IDE, only the Eclipse organization). So for example, I have a semantic engine for D (the equivalent of Racer) but it is written in Java, not D. And as such if I wanted to expose the engine functionality using the LSP protocol, I would naturally use LSP4J.

[liranringel]

Maybe lsp-rs?

[bruno-medeiros]

Updated the PR, rebased it to the latest commit, plus added a few changes. Haven't been able to test it because I can type-check rls, but not compile it fully (I get a GCC linker error..)

[nrc]

Thanks for the update. The RLS is a bit of a mess for compiling/testing atm due to changes to rustc and Cargo. I'll wait for those to resolve before trying to merge this.

[mrhota]

@bruno-medeiros @nrc ping

[bruno-medeiros]

I've started a new job this year, and I haven't been able to update this PR. Also, LSP itself has some changes (version 3.0 of the protocol), so RustLSP needs updating too.