Stream: t-compiler/wg-rls-2.0

Topic: rust-analyzer RFC


nikomatsakis (Apr 20 2020 at 14:40, on Zulip):

So @matklad on the topic of the RFC. Here is the current draft. Re-reading it, I think the summary doesn't seem right

nikomatsakis (Apr 20 2020 at 14:41, on Zulip):

I believe we had discussed a kind of "transition period", right

nikomatsakis (Apr 20 2020 at 14:41, on Zulip):

i.e., the idea was that we are declaring rust-analyzer as the "official IDE", but we're going to do the adoption in a few phases, beginning with the simple one of encouraging people to switch and give feedback

nikomatsakis (Apr 20 2020 at 14:41, on Zulip):

I feel like that is probably a better thing for the summary then what is there now

matklad (Apr 20 2020 at 14:42, on Zulip):

Yeah, the curent summary is not wrong, but it's not he most relevant thing.

nikomatsakis (Apr 20 2020 at 14:43, on Zulip):

I'm reading the rest and will drop a few notes here

nikomatsakis (Apr 20 2020 at 14:43, on Zulip):

One thing I want to particularly note is that we basically have no plan to adopt save-analysis anymore

nikomatsakis (Apr 20 2020 at 14:44, on Zulip):

nikomatsakis said:

I believe we had discussed a kind of "transition period", right

ah, good, there is good material on that already

nikomatsakis (Apr 20 2020 at 14:45, on Zulip):

The experience of installing rust-analyzer for other editors is more varied. The rust-analyzer project only directly supports VSCode. Other editor plugins are maintained independently.

@matklad is there a link we can drop in here?

matklad (Apr 20 2020 at 14:46, on Zulip):

Link to what? other editors?

nikomatsakis (Apr 20 2020 at 14:46, on Zulip):

Do you have some part of the rust-analyzer website that lists other extensions

nikomatsakis (Apr 20 2020 at 14:46, on Zulip):

the branding section is a bit confusing to me.

nikomatsakis (Apr 20 2020 at 14:46, on Zulip):

I am fine with keeping the rust-analyzer name.

matklad (Apr 20 2020 at 14:46, on Zulip):
matklad (Apr 20 2020 at 14:47, on Zulip):

Though the contents of those links admittedly needs some love

nikomatsakis (Apr 20 2020 at 14:47, on Zulip):

I guess https://rust-analyzer.github.io/manual.html#installation is probably the 'meta link' I was looking for

nikomatsakis (Apr 20 2020 at 14:48, on Zulip):

I just wanted to say something like "See the \[rust-analyzer manual\] for more information."

matklad (Apr 20 2020 at 14:48, on Zulip):

the branding section is a bit confusing to me.

uhu. Let's say "keep rust-analyzer name, at least for the transition period"?

nikomatsakis (Apr 20 2020 at 14:49, on Zulip):

nikomatsakis said:

the branding section is a bit confusing to me.

to say a bit more, the rust-analyzer org includes a fair number of repositories.

nikomatsakis (Apr 20 2020 at 14:50, on Zulip):

(Side note: the thing I worry most about here, that I'm not sure how to think about, is the rust-analyzer opencollective. Obviously there is no "rustc opencollective", and the line between the two is going to get blurrier and blurrier. But it feels like a problem we should be trying to address.)

nikomatsakis (Apr 20 2020 at 14:51, on Zulip):

(see also work towards foundation, although I think that will not necessarily address the whole problem, but let's not get too far into that discussion here.)

nikomatsakis (Apr 20 2020 at 14:51, on Zulip):

I guess I'd like the branding session to be a bit more concrete :)

nikomatsakis (Apr 20 2020 at 14:51, on Zulip):

In general, we have been consolidating things under the rust-lang github org, so probably we are going to move all the repositories there, at least eventually?

nikomatsakis (Apr 20 2020 at 14:52, on Zulip):

anyway, this might also be something we can hammer out after RFC is opened, in discussions with infra or whatever

matklad (Apr 20 2020 at 14:52, on Zulip):

In general, we have been consolidating things under the rust-lang github org, so probably we are going to move all the repositories there, at least eventually?

Yup. And maybe even merge the repos into one rust-analyzer monorepo

nikomatsakis (Apr 20 2020 at 14:53, on Zulip):

the website, btw, could become rust-analyzer.rust-lang.org

nikomatsakis (Apr 20 2020 at 14:53, on Zulip):

eventually, anyway

nikomatsakis (Apr 20 2020 at 14:53, on Zulip):

@simulacrum has been reminding me that we don't have to necessarily limit ourselves to github.io domains:)

matklad (Apr 20 2020 at 14:53, on Zulip):

Yeah.....

Hm, this actually is tough, in a sense that we'll accumulate a ton of stale URLs during transition period....

nikomatsakis (Apr 20 2020 at 14:54, on Zulip):

say more?

nikomatsakis (Apr 20 2020 at 14:55, on Zulip):

do you mean if we were to rename rust-analyzer, or do you just mean in the form of "moving repos"

matklad (Apr 20 2020 at 14:55, on Zulip):

Like, we have a known problem that google search results are plagued by first-edition of the book

nikomatsakis (Apr 20 2020 at 14:55, on Zulip):

(the stale URLs are a pain...)

nikomatsakis (Apr 20 2020 at 14:55, on Zulip):

I had hoped we'd be able to redirect

matklad (Apr 20 2020 at 14:56, on Zulip):

with RLS -> rust-analyzer -> unified rustc tool, we'd have a similar problem, unless we decide on the proper place for the docs from the start

matklad (Apr 20 2020 at 14:57, on Zulip):

To clarify, I think that the best path forward is maybe to just accept some (a lot?) of user confusion until the IDE-story crystallizes more.

nikomatsakis (Apr 20 2020 at 15:00, on Zulip):

Seems probable

nikomatsakis (Apr 20 2020 at 15:00, on Zulip):

I think it'd be pretty reasonable to have ide.rust-lang.org

nikomatsakis (Apr 20 2020 at 15:00, on Zulip):

that always contains up-to-date information about our recommended solution

nikomatsakis (Apr 20 2020 at 15:00, on Zulip):

for use in IDEs

nikomatsakis (Apr 20 2020 at 15:01, on Zulip):

it's hard to imagine that going stale :)

nikomatsakis (Apr 20 2020 at 15:01, on Zulip):

it also seems kind of orthogonal from this RFC

nikomatsakis (Apr 20 2020 at 15:01, on Zulip):

like, work we should do, but it's more of a general "improve the website" thing than anything

nikomatsakis (Apr 20 2020 at 15:01, on Zulip):

I'll list it as a possible "future step" or something

matklad (Apr 20 2020 at 15:03, on Zulip):

There's another thing on my mind: I've received complains from notable vim users (BurntSushi and simulacrum ) that rust-anlyzer's slow start up time is a deal breaker.

simulacrum (Apr 20 2020 at 15:03, on Zulip):

well, not so much a deal breaker, as 'annoying'

matklad (Apr 20 2020 at 15:03, on Zulip):

I think it is one for BurntSushi , which is an important data point

nikomatsakis (Apr 20 2020 at 15:03, on Zulip):

Is this in contrast to the existing RLS?

matklad (Apr 20 2020 at 15:03, on Zulip):

Yup

nikomatsakis (Apr 20 2020 at 15:03, on Zulip):

vim is certainly a very popular editor

nikomatsakis (Apr 20 2020 at 15:04, on Zulip):

That does seem important

simulacrum (Apr 20 2020 at 15:04, on Zulip):

(I've never used RLS, so can't comment there. I would say though that at least my vim workflow is usually open for a long time, where I then don't notice it much. But e.g. sitting down in the morning can be painful to wait for startup, especially because I don't really know when to stop waiting)

matklad (Apr 20 2020 at 15:05, on Zulip):

The are I think two issues here:

matklad (Apr 20 2020 at 15:07, on Zulip):

OTOH, node.js based plugin for rust-analyzer for vim seems like it has some momentum behind this: https://github.com/fannheyward/coc-rust-analyzer

So it's not like nobody can use ra with vim

Florian Diebold (Apr 20 2020 at 15:07, on Zulip):

my impression is that it depends on the workflow, but with (old-school) vim it's a pretty normal thing to open a file from the terminal, edit a bit and save and quit to edit something else

nikomatsakis (Apr 20 2020 at 15:10, on Zulip):

Yeah. That was certainly true for me when I used vi in .. oh .. 1996 or so :)

nikomatsakis (Apr 20 2020 at 15:10, on Zulip):

but I guess my experiences are a bit dated

nikomatsakis (Apr 20 2020 at 15:11, on Zulip):

/me has fond memories of writing perl in vi on a DEC VAX machine

bjorn3 (Apr 20 2020 at 15:16, on Zulip):

How much emoji reactions does Zulip allow on a single comment? :)

Jeremy Kolb (Apr 20 2020 at 15:21, on Zulip):

Regarding startup performance: should we focus on LSIF?

Jeremy Kolb (Apr 20 2020 at 15:22, on Zulip):

Or I guess... has that become more urgent?

matklad (Apr 20 2020 at 15:23, on Zulip):

I am pretty sure that LSIF is not a solution here. LSIF for our use case would be like a worse version of safe analysis, which we are migrating from :D

Laurențiu Nicola (Apr 20 2020 at 15:23, on Zulip):

There was a discussion about using save-analysis until we have something better in place

bjorn3 (Apr 20 2020 at 15:32, on Zulip):

Talk to fuchsia + facebook folks to figure out current state

Why is fuchsia or facebook related to rust-analyzer?

matklad (Apr 20 2020 at 15:33, on Zulip):

They are folks who use rust-analyzer in a huge monorepo setup, so they can clarify if rust-analyzer works for their use-case. And their use-case is important, as it is basically "worst-case" for IDE support

pksunkara (Apr 20 2020 at 15:36, on Zulip):

I am using this in https://github.com/clap-rs/clap which is a monorepo. Works good. But another monorepo at https://github.com/pksunkara/reign doesn't work as good because some crates use only some features from some crates and the check/build command is different for many crates

Edwin Cheng (Apr 20 2020 at 15:39, on Zulip):

What is the story about Macro in the RFC ? So would we use rustc macro code eventually ? Or it would be another library-ification ?

matklad (Apr 20 2020 at 15:40, on Zulip):

@Edwin Cheng I would think that yes, we'd love to library-ify macro expansion as well. Starting with shared token-tree structure between rustc and rust-analyzer.

matklad (Apr 20 2020 at 15:40, on Zulip):

Separetly from that, wasm-based proc macros is also somehting we need to handle....

Edwin Cheng (Apr 20 2020 at 15:45, on Zulip):

I think we have to figure out how hygiene works in RA first to confirm our token-tree structure is actually solid. Right ?

matklad (Apr 20 2020 at 15:46, on Zulip):

Right, I think after proc macros, hygine is probably the single non-technical unresolved question left in rust-analyzer

matklad (Apr 20 2020 at 15:47, on Zulip):

The two technical questions are:

Florian Diebold (Apr 20 2020 at 15:48, on Zulip):

local imports? :grimacing:

matklad (Apr 20 2020 at 15:50, on Zulip):

Sort-of? I feel that for local imports the design is more-or-less clear, and what is needed is "implementation" work, where the first step of "implementation" is creating a chalk-like strong bounday for name-reoslution IR

matklad (Apr 20 2020 at 15:50, on Zulip):

ok, yeah, having written that, I agree that name res is another unresolved thing. It always is.

nikomatsakis (Apr 20 2020 at 21:31, on Zulip):

@matklad ok, I think the RFC is basically ready now

nikomatsakis (Apr 20 2020 at 21:31, on Zulip):

I'm sorry, I got distracted for a while

nikomatsakis (Apr 20 2020 at 21:31, on Zulip):

by life

matklad (Apr 20 2020 at 21:32, on Zulip):

That's a very reasonable reason to be distracted!

nikomatsakis (Apr 20 2020 at 21:32, on Zulip):

oh hmm there are two sections on library-ification that seem to be about the same

nikomatsakis (Apr 20 2020 at 21:33, on Zulip):

I'll merge them

nikomatsakis (Apr 20 2020 at 21:37, on Zulip):

ok, I'm going to post

matklad (Apr 20 2020 at 21:37, on Zulip):

:thumbs_up:

nikomatsakis (Apr 20 2020 at 21:47, on Zulip):

Done: https://github.com/rust-lang/rfcs/pull/2912

matklad (Apr 20 2020 at 21:49, on Zulip):

:tada: thank you for putting the work into finishing the thing!

nikomatsakis (Apr 28 2020 at 11:42, on Zulip):

I messed on privmsg, but @matklad probably better to discuss here (also cc @Florian Diebold):

I wrote a summary comment that covers the RFC thread thus far. I wanted to call attention to the point about "full conformance" -- do you agree with what I wrote there?

I'll probably post this soon, though I am thinking of rewriting the "Feature parity" section to include a few more details. The TL;DR being "we are explicitly not requiring feature parity because we want to use feedback period to figure out which features are more important. some things are harder to build in the rust-analyzer infra without more refactoring, and we would have to create 'facade code' to throw away, and we don't want to do that" (referencing save-analysis, primarily).

nikomatsakis (Apr 28 2020 at 11:43, on Zulip):

In any case, just wanted to be sure you all were comfortable with those statements.

nikomatsakis (Apr 28 2020 at 11:44, on Zulip):

In particular, I think that the main differences from a feature parity perspective are

nikomatsakis (Apr 28 2020 at 11:44, on Zulip):

are there others?

matklad (Apr 28 2020 at 11:53, on Zulip):

because they do not support snippet-based completions, but rust-analyzer is sending them anyway.

That's already fixed in the latest (yesterday's ) release. I've found a neat way to implement compile-time checked honoring of snippet capability (via zero-sized, khm, capability token) and just couldn't resist implementing it right away :D

matklad (Apr 28 2020 at 11:58, on Zulip):

I do not however think that rust-analyzer necessarily needs to support older features, except where mandated by the protocol (but it should respect clients that don't support new ones)

I agree with this statement, but it is also somewhat vacuous, as the protocol more or less mandates support for older features. But I still think it's a good idea to have this stated explicitely.

nikomatsakis (Apr 28 2020 at 12:04, on Zulip):

that was something I wanted to check on...

nikomatsakis (Apr 28 2020 at 12:04, on Zulip):

...one other "feature", I guess, is caching and faster startup

matklad (Apr 28 2020 at 12:05, on Zulip):

I think this is well-motivated, but it's worth clarifying the stability story here

This is a good question. I think stability story should be different from compiler, in that using "unstable" features should require only an opt-in in the settings (ie, unstable rust-analyzer features should be available on the stable toolchain). I don't think there's ossification danger we need to protect from here, and making things more useful seems good.

nikomatsakis (Apr 28 2020 at 12:05, on Zulip):

hmm, I am not sure I had even expected that much

matklad (Apr 28 2020 at 12:05, on Zulip):

...one other "feature", I guess, is caching and faster startup

offtopic, I've recently realised that we should make rust-analyzer || before we implement persistance.

nikomatsakis (Apr 28 2020 at 12:06, on Zulip):

I was concerned about things like "emacs-lsp" supporting r-a extensions, and then some details of the extension change

nikomatsakis (Apr 28 2020 at 12:06, on Zulip):

but there is of course an analogous concern with an older vscode client

nikomatsakis (Apr 28 2020 at 12:06, on Zulip):

not sure how that is managed

nikomatsakis (Apr 28 2020 at 12:06, on Zulip):

(maybe the client just updates itself?)

matklad (Apr 28 2020 at 12:08, on Zulip):

So there's a bidirectional feature-detection from both client and server side in the protocol. If we implement this "properly" (and not just assume that client can do everything, as is the case today), we should be able to roll-out experimental features only if client agrees that they support it.

matklad (Apr 28 2020 at 12:08, on Zulip):

But it's true that if we, say, change the way we do inlay hints, non-vs-code clients would need some catch up time.

matklad (Apr 28 2020 at 12:09, on Zulip):

(though, in practice, folks seem to fix stuff relatively quickly for emacs at least)

matklad (Apr 28 2020 at 12:18, on Zulip):

support for precise, global find-all-uses and rename (relies on save-analysis)

are there others?

matklad (Apr 28 2020 at 12:18, on Zulip):

Other than that, :thumbs_up:

nikomatsakis (Apr 28 2020 at 12:27, on Zulip):

@matklad regarding extensions to the protocol, perhaps it suffices to say that "rust-analyzer should clarify the stability of each of the extensions it supports and document their status", something like that?

nikomatsakis (Apr 28 2020 at 12:28, on Zulip):

in theory, backwards incompatible changes to extensions could just use a new protocol name, I suppose (and the older one would not be supported)

nikomatsakis (Apr 28 2020 at 12:28, on Zulip):

I guess the other question is how much opt-in is required on the client side to access said features

nikomatsakis (Apr 28 2020 at 12:28, on Zulip):

I think that's kind of out of scope for the RFC itself personally, except to note that we should work it out

nikomatsakis (Apr 28 2020 at 12:29, on Zulip):

I guess I feel like it's not a semver violation if (e.g.) we decided to disable the type hints or other features

nikomatsakis (Apr 28 2020 at 12:31, on Zulip):

I guess I'll just copy your text which was basically :+1:

matklad (Apr 28 2020 at 12:31, on Zulip):

Yeah, "clarify & document" sounds good to me!

I guess I feel like it's not a semver violation if (e.g.) we decided to disable the type hints or other features

yup, this is what I am getting at.

nikomatsakis (Apr 28 2020 at 12:34, on Zulip):

@matklad does this sound ok for rfc text

Furthermore, rust-analyzer currently supports some extensions to the core LSP protocol, to support
features that the core LSP does not yet support. Some examples include:

rust-analyzer will document the status and stability of these
extensions. Further, disruptive or particulrly unstable extensions
will be made opt-in (via client settings) until they are suitable for
wider use. However, we do not consider it a "semver violation" to
remove support for extensions if they don't seem to be working out, as
the LSP protocol already permits a negotiation between client and
server with respect to which extensions are supported.

matklad (Apr 28 2020 at 12:35, on Zulip):

Almost! The factual mistake is that the first two started as extensions, but are now fully suported by the LSP

nikomatsakis (Apr 28 2020 at 12:36, on Zulip):

I was wondering about that, ok

matklad (Apr 28 2020 at 12:36, on Zulip):

I guess s/currently supports/sometimes implements/ would work for past & present

nikomatsakis (Apr 28 2020 at 12:37, on Zulip):

updated to

Furthermore, rust-analyzer currently supports some extensions to the
core LSP protocol, to support features that the core LSP does not yet
support. Some examples include:

In some cases, these extensions go on to become part of the standard
protocol, as happened with these two extensions:

rust-analyzer will document the status and stability of these
extensions. Further, disruptive or unstable extensions will be made
opt-in (via client settings) until they are suitable for wider
use. However, we do not consider it a "semver violation" to remove
support for extensions if they don't seem to be working out, as the
LSP protocol already permits a negotiation between client and server
with respect to which extensions are supported.

nikomatsakis (Apr 28 2020 at 12:37, on Zulip):

I think it's worth noting that some got adopted

matklad (Apr 28 2020 at 12:37, on Zulip):

Yup, perfect!

nikomatsakis (Apr 28 2020 at 12:37, on Zulip):

OK

Florian Diebold (Apr 28 2020 at 12:38, on Zulip):

that's a lot of "supports" in the first sentence though ;)

nikomatsakis (Apr 28 2020 at 13:13, on Zulip):

OK, I updated the feature parity section of the comment and I plan to post

nikomatsakis (Apr 28 2020 at 13:21, on Zulip):

posted comment

Laurențiu Nicola (May 22 2020 at 18:02, on Zulip):

Huh, weren't FCPs supposed to last 7 days? https://github.com/rust-lang/rfcs/pull/2912#issuecomment-628013908

Florian Diebold (May 22 2020 at 18:16, on Zulip):

14 days AFAIK

simulacrum (May 22 2020 at 18:16, on Zulip):

10 days is what the bot says, I think

Laurențiu Nicola (May 22 2020 at 18:19, on Zulip):

The FCP lasts ten calendar days, so that it is open for at least 5 business days.

Laurențiu Nicola (May 22 2020 at 18:19, on Zulip):

Yeah, it must have changed. But some RFCs still seem to get merged after 7 days.

bjorn3 (May 22 2020 at 18:40, on Zulip):

https://github.com/rust-lang/rfcbot-rs/blob/c02bfcf5263c9a76751cd33e510e57434c07ef7b/src/github/nag.rs#L454

Laurențiu Nicola (May 28 2020 at 11:25, on Zulip):

https://github.com/rust-lang/rfcs/pull/2912 is still not merged, though

Laurențiu Nicola (May 29 2020 at 15:38, on Zulip):

@nikomatsakis ^ :slight_smile:

nikomatsakis (May 29 2020 at 17:43, on Zulip):

Yes, I'll merge it...

Last update: Sep 30 2020 at 16:15UTC