Skip to content
This repository has been archived by the owner on Dec 29, 2022. It is now read-only.

Dependency triaging RLS and async/await #1695

Closed
workingjubilee opened this issue Sep 3, 2020 · 3 comments · Fixed by #1741
Closed

Dependency triaging RLS and async/await #1695

workingjubilee opened this issue Sep 3, 2020 · 3 comments · Fixed by #1741
Assignees

Comments

@workingjubilee
Copy link
Member

While rust-analyzer is the preferred LSP solution, rust-analyzer still cannot fully replace RLS and RLS is still a tested submodule of rustc, and will likely be used for some time by the community. Accordingly, RLS could use a little tender love and care to its dependency tree, as rust-analyzer has gotten most of the action here.

A main source of "dependency decay"... dependence on old code that isn't getting much security/compat/enhancement maintenance... is the usage of mostly pre-async/await code in RLS and its dependencies. This currently keeps RLS stuck on an older version of futures and tokio. There are three major, obvious options:

  1. Wait for Switch to std::future::Future paritytech/jsonrpc#485 to resolve
    Pros: Lazy!
    Cons: Parity began work on jsonrpsee to replace it, so it may never be moved fully over to tokio 0.2
  2. Move jsonrpc -> https://github.com/paritytech/jsonrpsee as it becomes available
    Pros: Newer, maintained dep, eventually no loss of features?
    Cons: New, untested, possibly feature-incomplete for RLS' use-case.
  3. Write some blocking JSON IPC as suggested here Remove duplicate dependencies for rustc itself rust#75704 (comment)
    Pros: Less dependence on complicated/newer features. Simplifies dependency tree greatly.
    Cons: Forfeiting async benefits, more effort, taking on maintenance burden directly
@cuviper
Copy link
Member

cuviper commented Nov 17, 2020

The current dependency chain is also an issue for aarch64 windows: #1693.

@Xanewok
Copy link
Member

Xanewok commented Nov 18, 2020

I'll look into this this week; @workingjubilee thank you for the detailed write-up!

@Xanewok Xanewok self-assigned this Nov 18, 2020
@Xanewok
Copy link
Member

Xanewok commented Jan 15, 2021

Update: paritytech/jsonrpc#485 is now fixed via paritytech/jsonrpc#603, so I believe this should be the way forward here, once jsonrpc is released including that PR.

@Xanewok Xanewok mentioned this issue Jan 20, 2021
bors added a commit that referenced this issue Jan 20, 2021
Use Tokio 0.2

Helps with #1695 and #1693 (still needs a bump to Tokio 1.0)
@Xanewok Xanewok mentioned this issue Jun 29, 2021
2 tasks
@bors bors closed this as completed in 7dfa30b Aug 24, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants