Stream: t-compiler/rust-analyzer

Topic: rust-analyzer#775

Caio (Mar 20 2019 at 11:35, on Zulip):

What is the status of #775? Should EOL be converted or preserved?

matklad (Mar 20 2019 at 12:03, on Zulip):

@Caio it needs design and implementation. I am not actually sure that the proposed solution is a good one, but it seems nice

matklad (Mar 20 2019 at 12:03, on Zulip):

Basically, we make it an invariant that any strings inside rust-analyzer use \n as a line separator, and that any transcoding happens at the boundary

matklad (Mar 20 2019 at 12:03, on Zulip):

sort-of how python's text mode works

matklad (Mar 20 2019 at 12:04, on Zulip):

I guess the next step is to write some experimental impl which tries to convert line-endings at the lsp boundary

matklad (Mar 20 2019 at 12:06, on Zulip):

Changes in one direciton (text going from editor into analyzer) should be handled here:

Caio (Mar 21 2019 at 00:02, on Zulip):

@matklad Thanks! I guess it is going to take a while since I am still learning how rust-analyzer works

pachi (Mar 22 2019 at 08:23, on Zulip):

@matklad I suppose you're already aware, but there's a grammar WG which already has a parser and grammar for Rust that may be interesting to consider for r-a. @centril and @eddyb are part of the group

matklad (Mar 22 2019 at 08:28, on Zulip):

I am aware of that, yeah. The plan is to fuzz ra parser against the grammar, once that is ready.

We probably won't be able to reuse grammar/parser as is: we must deal with incomplete code well, and we need to be able to produce concrete syntax trees. We definitely should align the names of various types though!

pachi (Mar 22 2019 at 08:37, on Zulip):

Fantastic, I just wanted to make sure that you were aware of each other's work :)

Last update: Jul 29 2021 at 08:45UTC