Stream: t-compiler/rust-analyzer

Topic: Getting gen_lsp_server working

D. Moonfire (May 21 2019 at 21:35, on Zulip):

I'm trying to figure out why I can't get gen_lsp_server working and it appears to be hanging on the threaded stdin/stdout logic in I think it is because we are doing something on both the stdin and the stdout at the same time.

I managed to get it down to a minimal case using code stolen from that crate ( but I'm not sure how to get around the blocking error. If I comment lines 37-42, it works fine but that obviously isn't what it was indented.

I found a few other examples of it, but the only one that I understood uses futures which doesn't appear to be used by gen_lsp_server. Since I have to work with private structs in that crate, I figured I would have to match the libraries used in that example so futures doesn't have a future unless something changes.

Any chance someone can point me to a way of figuring this out?

matklad (May 22 2019 at 07:31, on Zulip):

WHere exactly does it hang?

matklad (May 22 2019 at 07:31, on Zulip):

If that's the join call, than the issue might be an unclosed stdout on the other side

matklad (May 22 2019 at 07:31, on Zulip):

matklad (May 22 2019 at 07:32, on Zulip):

The way I would debug this is to add logging to the lowest possible level, stdio transport, to figure out which message can't get through

D. Moonfire (May 22 2019 at 13:46, on Zulip):

It was on the let req = match receiver.recv() { call. However I decided to try something and switched logging libraries (to handle the trace!) and made sure all the logging output was going to stderr. Apparently the logging library (simple_logger) was conflicting with the stdout.lock(), which makes sense in hindsight. Thank you.

Last update: Jul 24 2021 at 21:15UTC