Stream: t-compiler/wg-rls-2.0

Topic: rust-analyzer in gnome-builder


bronze alibi (Mar 28 2020 at 15:03, on Zulip):

Hello everybody! :)
Has anyone of you tested rust-analyzer with gnome-builder yet?

Laurențiu Nicola (Mar 28 2020 at 15:25, on Zulip):

It doesn't seem to support LSP

Laurențiu Nicola (Mar 28 2020 at 15:26, on Zulip):

https://wiki.gnome.org/Projects/Vala/Tools#Language_Server_Protocol_Support or maybe it does?

Laurențiu Nicola (Mar 28 2020 at 15:28, on Zulip):

I can't see any way to configure which server to use

Laurențiu Nicola (Mar 28 2020 at 15:34, on Zulip):

I tried to make it spawn rust-analyzer instead of rls, but it's not working

Laurențiu Nicola (Mar 28 2020 at 15:47, on Zulip):

I haven't looked into it too deeply, but it looks like it's trying to load my entire ~, and it also panics a little from time to time. Using the wrong path is definitely a problem, though.

bronze alibi (Mar 28 2020 at 15:52, on Zulip):

Laurențiu Nicola said:

There's no way to configure which server to use

Yeah it looks like they have a plugin for rls, but no generalized use whatever language server you want support.

Laurențiu Nicola (Mar 28 2020 at 15:57, on Zulip):

@matklad does RUST_LOG=gen_lsp_server=trace still work? and does it log to stderr?

Laurențiu Nicola (Mar 28 2020 at 16:05, on Zulip):

Filed https://github.com/rust-analyzer/rust-analyzer/issues/3758.

bronze alibi (Mar 28 2020 at 16:25, on Zulip):

I guess that would be for the gnome-builder team to decide, but - from your perspective - would it make more sense to have generalized any language server support in builder, or a toggle on the rls plugin to switch between (legacy)rls and rust-analyzer?

Laurențiu Nicola (Mar 28 2020 at 16:47, on Zulip):

I don't know. They seem to prefer having different plugins (e.g. gcc and clang). The rust-analyzer one could be pretty much identical to the RLS plugin. Or maybe they'll do nothing and wait until rust-analyzer replaces RLS (if that ever happens).

Laurențiu Nicola (Mar 28 2020 at 16:49, on Zulip):

Gee, I wonder what's the best way to intercept the stdout and stderr of a running program.

bjorn3 (Mar 28 2020 at 16:52, on Zulip):

You could use reptyr. It uses ptrace to make the target process perform the necessary steps to change its pty.

bjorn3 (Mar 28 2020 at 16:52, on Zulip):

More details how it works here: https://blog.nelhage.com/2011/02/changing-ctty/

Laurențiu Nicola (Mar 28 2020 at 16:54, on Zulip):

I tried to use it once to recover a backgrounded program, but it didn't work for me. And I don't want to steal the fds, but rather eavesdrop on them

Laurențiu Nicola (Mar 28 2020 at 16:54, on Zulip):

I usually strace the process, but it's a bit awkward when someone else spawns it

bjorn3 (Mar 28 2020 at 16:55, on Zulip):

I had to use it once when Xorg crashed due to a failing GPU. It worked fine for me.

Laurențiu Nicola (Mar 28 2020 at 16:57, on Zulip):

It seems to use dup2, so I guess it's not what I'm looking for

bjorn3 (Mar 28 2020 at 16:58, on Zulip):

https://unix.stackexchange.com/questions/58550/how-to-view-the-output-of-a-running-process-in-another-bash-session/308666#308666

tail -f /proc/<pid>/fd/1

Maybe that works?

bjorn3 (Mar 28 2020 at 16:59, on Zulip):

This won't work if the output is going to a tty (or redirected to /dev/null) — it will only work if the output is redirected to a file.

Maybe not

Laurențiu Nicola (Mar 28 2020 at 17:00, on Zulip):
tail: cannot open '/proc/67363/fd/1' for reading: No such device or address
bjorn3 (Mar 28 2020 at 17:01, on Zulip):

The other suggestions on that page are using strace and then parsing the output

Laurențiu Nicola (Mar 28 2020 at 17:02, on Zulip):

Sounds like a fun project

bjorn3 (Mar 28 2020 at 17:04, on Zulip):

One of the snippets on the page worked:

strace -e trace=write -s1000 -fp $pid 2>&1 \
| grep --line-buffered -o '".\+[^"]"' \
| grep --line-buffered -o '[^"]\+[^"]' \
| while read -r line; do
  printf "%b" $line;
done
Laurențiu Nicola (Mar 28 2020 at 19:07, on Zulip):

I ended up writing a small program that logs the console IO and passes it through to a child process, but I still can't figure out what the issue is :slight_smile:

Jeremy Kolb (Mar 28 2020 at 19:35, on Zulip):

Does it send any LSP requests at all or do you not make it that far? We don't check a lot of client caps so I could see us returning newer things than are supported by gnome builder

Laurențiu Nicola (Mar 28 2020 at 19:37, on Zulip):

It does, but we crash with an OOB access when converting the position: https://github.com/rust-analyzer/rust-analyzer/issues/3758#issuecomment-605501732

Laurențiu Nicola (Mar 28 2020 at 19:37, on Zulip):

Not sure why

Laurențiu Nicola (Mar 28 2020 at 19:38, on Zulip):

I tried to debug it, but the CodeLLDB breakpoints don't seem to work on my system

Jeremy Kolb (Mar 28 2020 at 19:45, on Zulip):

Can you try in vscode and see what the LSP is?

Laurențiu Nicola (Mar 28 2020 at 20:01, on Zulip):

Not easily :-)

Jeremy Kolb (Mar 28 2020 at 20:03, on Zulip):

I tried it out on your example and it always sends the entire file contents in the didChange. That's the only different I see in that particular request/response

Jeremy Kolb (Mar 28 2020 at 20:10, on Zulip):

ahhh I think the gnome builder lsp client isn't respecting the server's choice of full text synchronization

Laurențiu Nicola (Mar 28 2020 at 20:11, on Zulip):

And maybe we take the text from the request instead of our version, so it only has one character

Jeremy Kolb (Mar 28 2020 at 20:12, on Zulip):

Yeah I think that's probably the issue

Laurențiu Nicola (Mar 28 2020 at 20:17, on Zulip):

Maybe we should support partial synchronization

Laurențiu Nicola (Mar 28 2020 at 20:35, on Zulip):

@bronze alibi do you want to give it a try?

bronze alibi (Mar 28 2020 at 20:59, on Zulip):

Laurențiu Nicola said:

bronze alibi do you want to give it a try?

try what?

Laurențiu Nicola (Mar 28 2020 at 21:00, on Zulip):

Implementing incremental text synchronization support in rust-analyzer. Right now it expects editors to send the full file contents on each edit, but there's a mode where the editor can send only the differences.

Laurențiu Nicola (Mar 28 2020 at 21:03, on Zulip):

I think it's a matter of passing the edits through a couple of layers of method calls, then actually applying them. You'd also need to do a line/column -> byte offset conversion, not sure exactly where.

bronze alibi (Mar 28 2020 at 21:03, on Zulip):

I am not familiar with the rust-analyzer codebase and a one university semester coder, so I am not sure I could pull that off.

Laurențiu Nicola (Mar 28 2020 at 21:06, on Zulip):

If you want to take a look, you can start from https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/rust-analyzer/src/main_loop.rs#L598-L599. params.content_changes contains all the changes, but the code only picks one and passes it through. Changes look like this, where an empty range means that the full file needs to be replaced.

bronze alibi (Mar 28 2020 at 21:11, on Zulip):

I appreciate your helpfulness and I will take a look at it, but I am quite certain that this is quite far beyond my level of understanding.
I think it would make a lot of sense for you to copy the text your wrote on what to do to the github issue, so someone else too can have an easier time, too.

Laurențiu Nicola (Mar 28 2020 at 21:20, on Zulip):

Sure, filed https://github.com/rust-analyzer/rust-analyzer/issues/3762.

bronze alibi (Mar 28 2020 at 21:24, on Zulip):

Cool. I really appreciate this community here. A one sentence question that could have reasonably been just met with just a "no", let to 3 people responding with a little cooperative investigation and 2 issues filed.
This is work too, and I thank y'all for taking the time!

Laurențiu Nicola (Mar 28 2020 at 21:29, on Zulip):

Well, it looks like Code sends an update on each keypress so this might make rust-analyzer a tiny bit faster

Jeremy Kolb (Mar 29 2020 at 15:39, on Zulip):

I'm surprised that gnome builder doesn't support Full mode since that sounds easier to implement. I wonder if there's an option.

bjorn3 (Mar 29 2020 at 16:40, on Zulip):

Maybe they wanted to implement the most efficient mode first instead of the easiest, as they would likely want to implement the most efficient mode at some point anyway.

matklad (Mar 29 2020 at 17:34, on Zulip):

Well, it looks like Code sends an update on each keypress so this might make rust-analyzer a tiny bit faster

They actually, for a full-sync mode, have a debouncing rate inside of the editor

Laurențiu Nicola (Mar 29 2020 at 17:53, on Zulip):

matklad said:

They actually, for a full-sync mode, have a debouncing rate inside of the editor

Strange, am I typing too slow? :-). I didn't notice any debouncing.

matklad (Mar 29 2020 at 18:23, on Zulip):

https://github.com/microsoft/vscode-languageserver-node/blob/b1f6a443efad3d61cf83344589099dab5318ca66/client/src/client.ts#L1003-L1029

Laurențiu Nicola (Mar 29 2020 at 18:27, on Zulip):

image.png

Laurențiu Nicola (May 01 2020 at 08:25, on Zulip):

@bronze alibi not sure if you've been following that GitHub issue, but Builder should be supported in the latest nightly. There are some instructions here: https://github.com/rust-analyzer/rust-analyzer/pull/4236/files. Testing it would be welcome :-).

Last update: May 29 2020 at 17:35UTC