Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert to std::future and async/await #58

Closed
ebkalderon opened this issue Nov 8, 2019 · 4 comments · Fixed by #101
Closed

Convert to std::future and async/await #58

ebkalderon opened this issue Nov 8, 2019 · 4 comments · Fixed by #101
Assignees
Labels
enhancement New feature or request

Comments

@ebkalderon
Copy link
Owner

With async/await stabilizing in Rust 1.39.0, this library should be ported to use the new syntax and switch to std::future::Future. This should involve upgrading tower-service to version 0.3.0alpha.2 and switching away from jsonrpc_core to the brand-new jsonrpsee crate.

Unfortunately, jsonrpsee does not provide a stdio transport at the time of writing. Since this is a hard requirement for virtually all LSP servers, we will have to wait until support is implemented.

@ebkalderon ebkalderon added the enhancement New feature or request label Nov 8, 2019
ebkalderon added a commit that referenced this issue Feb 22, 2020
This commit makes judicious use of `compat()` to convert between
`std::future::Future` and the legacy `futures` 0.1 `Future` trait such
that we can have native Rust async/await support without waiting for the
`jsonrpsee` crate to be ready (see #58 for
context).

Naturally, this should be considered a breaking change for this library
since it directly affects the public API for this crate. It tentatively
introduces a reliance on [`async-trait`] for the `LanguageServer` trait
and it also relaxes the `'static` requirements for the `stdin` parameter
for `Server`.

[`async-trait`]: https://github.com/dtolnay/async-trait

This does not yet resolve #13, since that would
require either switching to `jsonrpsee` or building a custom client
solution for the `Printer`, converting it to a `Client` or similar.
ebkalderon added a commit that referenced this issue Feb 22, 2020
This commit makes judicious use of `compat()` to convert between
`std::future::Future` and the legacy `futures` 0.1 `Future` trait such
that we can have native Rust async/await support without waiting for the
`jsonrpsee` crate to be ready (see #58 for
context).

Naturally, this should be considered a breaking change for this library
since it directly affects the public API for this crate, and it also
increases the minimum supported Rust version to 1.39.0. It tentatively
introduces a reliance on [`async-trait`] for the `LanguageServer` trait
and it also relaxes the `'static` requirements for the `stdin` parameter
for `Server`.

[`async-trait`]: https://github.com/dtolnay/async-trait

This does not yet resolve #13, since that would
require either switching to `jsonrpsee` or building a custom client
solution for the `Printer`, converting it to a `Client` or similar.
@ebkalderon
Copy link
Owner Author

@icsaszar FYI, I have an experimental branch with async/await support here. Creating a pull request from this and merging it would affect your efforts on #100, though, so I'm waiting a bit. Feel free to read through the commit messages and see what has changed!

ebkalderon added a commit that referenced this issue Feb 22, 2020
This commit makes judicious use of `compat()` to convert between
`std::future::Future` and the legacy `futures` 0.1 `Future` trait such
that we can have native Rust async/await support without waiting for the
`jsonrpsee` crate to be ready (see #58 for context).

Naturally, this should be considered a breaking change for this library
since it directly affects the public API for this crate, and it also
increases the minimum supported Rust version to 1.39.0. It tentatively
introduces a reliance on [`async-trait`] for the `LanguageServer` trait
and it also relaxes the `'static` requirements for the `stdin` parameter
for `Server`.

[`async-trait`]: https://github.com/dtolnay/async-trait

This does not yet resolve #13, since that would require either
switching to `jsonrpsee`, once it's ready, or building a custom client
solution for the `Printer`, converting it to a `Client` or similar.
@icsaszar
Copy link
Contributor

@ebkalderon You can go ahead and merge it if you're ready, I was waiting for feedback on #100, so I haven't started yet.

@ebkalderon
Copy link
Owner Author

Okay, sounds good! Do you personally find the new trait API with async-trait acceptable? Would any of the changes have any negative impact on your current projects?

@ebkalderon
Copy link
Owner Author

@icsaszar This issue will be closed as a result of merging #101, but feel free to leave your comments in a new issue if you have any concerns for your project! I don't plan on making a brand-new release on Crates.io until #100 is resolved as well.

ebkalderon added a commit that referenced this issue Feb 22, 2020
This commit makes judicious use of `compat()` to convert between
`std::future::Future` and the legacy `futures` 0.1 `Future` trait such
that we can have native Rust async/await support without waiting for the
`jsonrpsee` crate to be ready (see #58 for context).

Naturally, this should be considered a breaking change for this library
since it directly affects the public API for this crate, and it also
increases the minimum supported Rust version to 1.39.0. It tentatively
introduces a reliance on [`async-trait`] for the `LanguageServer` trait
and it also relaxes the `'static` requirements for the `stdin` parameter
for `Server`.

[`async-trait`]: https://github.com/dtolnay/async-trait

This does not yet resolve #13, since that would require either
switching to `jsonrpsee`, once it's ready, or building a custom client
solution for the `Printer`, converting it to a `Client` or similar.
@ebkalderon ebkalderon self-assigned this Apr 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants