oxalica / async-lsp

Asynchronous Language Server Protocol framework
Apache License 2.0
68 stars 8 forks source link

Compiling to `wasm32-wasi` target #8

Closed micahscopes closed 6 months ago

micahscopes commented 9 months ago

I was able to get the server trait example to compile to wasm32-wasi with a few considerations:

I made dummy AsyncRead and AsyncWrite just to get it to compile but haven't actually hooked up anything useful. My usecase is to eventually run the language server in the browser and I wanted to make sure I could get async-lsp to compile to WASI for use with something like wasmer-js.

I'm not sure if it's worth documenting this in the readme, but I at least wanted to make this issue in case anyone else is trying this.

oxalica commented 9 months ago

Thanks for the test.

  • It's necessary to disable unsupported features from both async-lsp and tokio, specifically tokio/io-std

I think tokio/io-std should be able to support WASI, but it's up to them and is not actionable here.

and async-lsp/client-monitor

waitpid-any does not and will not support WASI, since relevant syscalls are missing. So this is intended.

Are you expecting these features being removed from the default feature set?

  • I also needed to limit use of any async-std dependency to non-wasm targets: I made dummy AsyncRead and AsyncWrite just to get it to compile but haven't actually hooked up anything useful.

We currently does not depend on async-std. Only futures::Async{Read,Write} interfaces are used under stdio feature. I don't think there is any compatibility issue about this.

I'm not sure if it's worth documenting this in the readme

PRs are welcome.

wiiznokes commented 9 months ago

Wanted to give this idea a shot too. I initially compiled succefully lsp-server to wasm but this crate seems way better. I wonder if spawning the server in a worker is feasible/a good idea.

micahscopes commented 9 months ago

Are you expecting these features being removed from the default feature set?

@oxalica not necessarily, though that might not be a bad idea. Mostly I just wanted to document this so that others who are interested in the WASI target don't have put as much effort in.

I wonder if spawning the server in a worker is feasible/a good idea.

@wiiznokes you might be interested in @wasmer/sdk. I still haven't figured out how to properly set up IO in the WASI build but I don't see anything preventing that. I guess you could make AsyncRead and AsyncWrite adapters for the WASI io interface. I haven't found a crate for that yet though or dug into how to do that. Otherwise maybe you could make async adapters for a MesaageChannel passed to the worker?

oxalica commented 6 months ago

Close as no actions needed. It should already work with default features disabled.