Stream: t-compiler

Topic: rls / rust-analyzer planing


matklad (Sep 19 2019 at 12:40, on Zulip):

A placeholder stream for rls/rust-analyer planing meeting. Link to event: https://calendar.google.com/event?action=TEMPLATE&tmeid=NTNxdXU4MDQ0ZDFsZ2lkamk1NTcwcTY4dHVfMjAxOTA5MTlUMTQwMDAwWiA2dTVycnRjZTZscnR2MDdwZmkzZGFtZ2p1c0Bn&tmsrc=6u5rrtce6lrtv07pfi3damgjus%40group.calendar.google.com&scp=ALL

Goal of the meeting: find out medium-term plan for rls and rust analyzer: support both, focus on one, merge?

matklad (Sep 19 2019 at 12:40, on Zulip):

cc @WG-rls2.0

Florian Diebold (Sep 19 2019 at 13:39, on Zulip):

@matklad that link goes to the Compiler Team Triage Meeting... that's not it, right?

matklad (Sep 19 2019 at 13:40, on Zulip):

@Florian Diebold indeed, thanks, fixed!

Igor Matuszewski (Sep 19 2019 at 16:00, on Zulip):

@matklad that's in an hour, right? I'm confused if Google inferred a good time zone here

matklad (Sep 19 2019 at 16:08, on Zulip):

Right, it's in an hour

Igor Matuszewski (Sep 19 2019 at 16:10, on Zulip):

okay, thanks

Igor Matuszewski (Sep 19 2019 at 17:00, on Zulip):

:wave:

matklad (Sep 19 2019 at 17:00, on Zulip):

Hello!

matklad (Sep 19 2019 at 17:01, on Zulip):

@Florian Diebold , @nikomatsakis are you around?

Florian Diebold (Sep 19 2019 at 17:02, on Zulip):

yeah

matklad (Sep 19 2019 at 17:05, on Zulip):

ping @nikomatsakis :)

nikomatsakis (Sep 19 2019 at 17:06, on Zulip):

I'm here now

nikomatsakis (Sep 19 2019 at 17:06, on Zulip):

sorry, had to grab coffee

matklad (Sep 19 2019 at 17:06, on Zulip):

Ok, so let's get started

nikomatsakis (Sep 19 2019 at 17:07, on Zulip):

Maybe start by outlining our goals?

matklad (Sep 19 2019 at 17:08, on Zulip):

Right

matklad (Sep 19 2019 at 17:08, on Zulip):

Maybe even from outlining a problem, as I am not sure what the right goal is

matklad (Sep 19 2019 at 17:08, on Zulip):

The probelm is that we have two independent code bases, rust-analyzer and rls

nikomatsakis (Sep 19 2019 at 17:08, on Zulip):

Yep :)

matklad (Sep 19 2019 at 17:09, on Zulip):

That is bad for two reasons:

nikomatsakis (Sep 19 2019 at 17:10, on Zulip):

Yep

Igor Matuszewski (Sep 19 2019 at 17:10, on Zulip):

Unfortunately it is confusing, indeed. I'd like for us to find a common direction

nikomatsakis (Sep 19 2019 at 17:10, on Zulip):

I'm particularly concerned about users

nikomatsakis (Sep 19 2019 at 17:10, on Zulip):

Though resources are bad too

nikomatsakis (Sep 19 2019 at 17:11, on Zulip):

I guess I think there is a third bullet of kind of "internal team cohesion"

matklad (Sep 19 2019 at 17:11, on Zulip):

Yeah, not only the users are confused, we are also confused :)

nikomatsakis (Sep 19 2019 at 17:11, on Zulip):

luckily we're all friendly folk, but this is the kind of split from which bad things could emerge :)

nikomatsakis (Sep 19 2019 at 17:11, on Zulip):

Maybe worth sketching out what some "end states" might look like? I don't mean all the way to the end, but kind of "intermediate end state"

nikomatsakis (Sep 19 2019 at 17:12, on Zulip):

I think @matklad you were hypothesizing, for example, that we could maybe have a unified RLS which uses (say) save-analysis and RLS plumbing for somethings, and rust-analyzer for the rest?

matklad (Sep 19 2019 at 17:12, on Zulip):

Note that, for rust-analyzer, at the moment, there's this important characteristic: it prioritizes experementation over direct user's satisfaction

nikomatsakis (Sep 19 2019 at 17:12, on Zulip):

And I think that's a quality we'd like to preserve

Igor Matuszewski (Sep 19 2019 at 17:13, on Zulip):

Speaking of the medium-term goal mentioned in the OP, I'd like to bring up the elephant in the room, which is possibility of moving off the RLS

Igor Matuszewski (Sep 19 2019 at 17:13, on Zulip):

Truthfully it'd be a shame to abandon the existing setup, and I like the fact that it's slow (well maybe not that) but correct

Igor Matuszewski (Sep 19 2019 at 17:13, on Zulip):

which sort of ties in with the experimental nature of the RA

nikomatsakis (Sep 19 2019 at 17:14, on Zulip):

Right so I guess in broad strokes we could either (a) give up on existing RLS, (b) try to combine somehow with r-a, or (c) give up on r-a, but I think we're not really ready for a or c, and we're here to discuss if there is a fruitful version of (b)?

Igor Matuszewski (Sep 19 2019 at 17:14, on Zulip):

I think that the RA experiment has shown that incremental infra alone will does not offset the cost of the current architecture of the RLS - change -> rebuild the entire compilation DB

nikomatsakis (Sep 19 2019 at 17:14, on Zulip):

I'm not quite sure @Igor Matuszewski what that statement means, can you rephrase?

Igor Matuszewski (Sep 19 2019 at 17:15, on Zulip):

yes, sorry, meant to follow that up

matklad (Sep 19 2019 at 17:15, on Zulip):

I don't think we will really abandon existing things, even if we move off completely from RLS.

For example, IIRC cargo check is the result of RLS work, and it's here to stay. I also feel that save-analysis is a great tool for offline processing, and that, for example, we should market cargo src more

Igor Matuszewski (Sep 19 2019 at 17:15, on Zulip):

I like the fact that RLS is already shipped with Rustup and works directly with rustc itself (in terms of feature "parity")

Igor Matuszewski (Sep 19 2019 at 17:16, on Zulip):

but it shows that we can't maintain the current architecture anymore

Igor Matuszewski (Sep 19 2019 at 17:16, on Zulip):

so I'd like to propose to maybe move the RLS to leverage the now-existing infrastructure for queries instead of relying on save-analysis

Igor Matuszewski (Sep 19 2019 at 17:17, on Zulip):

this would be the more stable of the option whereas the RA could still experiment and find out ways how we could librarify the stuff on the rustc side itself

Igor Matuszewski (Sep 19 2019 at 17:17, on Zulip):

but that doesn't solve the 'should I use tool A or B' problem...

nikomatsakis (Sep 19 2019 at 17:17, on Zulip):

but it shows that we can't maintain the current architecture anymore

what shows that?

Igor Matuszewski (Sep 19 2019 at 17:18, on Zulip):

(disregard, I may have went in the wrong direction)

Igor Matuszewski (Sep 19 2019 at 17:18, on Zulip):

@nikomatsakis I think one example is hiridication and recent ICE fixes in the save-analysis generation

Igor Matuszewski (Sep 19 2019 at 17:18, on Zulip):

it being an AST walker with additional setup is slightly dated and it shows; I wonder if we could find a way to just use query system directly

nikomatsakis (Sep 19 2019 at 17:18, on Zulip):

OK, I thought that might be what you meant

Igor Matuszewski (Sep 19 2019 at 17:19, on Zulip):

I don't think not touching existing setup is required, even if we pursue the offline indexing feature a la LSIF/current save-analysis index file

matklad (Sep 19 2019 at 17:19, on Zulip):

existing setup = save-analysis, right?

nikomatsakis (Sep 19 2019 at 17:20, on Zulip):

Certainly in the past we had thought about trying to convert save-analysis to be built from queries

nikomatsakis (Sep 19 2019 at 17:20, on Zulip):

as an intermediate step

nikomatsakis (Sep 19 2019 at 17:20, on Zulip):

that seems somewhat orthogonal tho

Igor Matuszewski (Sep 19 2019 at 17:20, on Zulip):

Yes, let's get back to that later

nikomatsakis (Sep 19 2019 at 17:20, on Zulip):

(well I guess it depends on the specifics of what we do)

matklad (Sep 19 2019 at 17:21, on Zulip):

Yeah, I guess it makes sense to canvas overall approaches available to us

nikomatsakis (Sep 19 2019 at 17:21, on Zulip):

In any case, I'm certainly curious if there is a way to put the two systems into one unified harness, and what that would mean. I definitely agree with @Igor Matuszewski we want to preserve the "distributed through rustup" and "correct" nature, and agree with @mw that -- ideally -- we'd continue to enable experimentation in r-a without being locked into "back-compat".

nikomatsakis (Sep 19 2019 at 17:21, on Zulip):

er, @matklad I mean, not @mw

Florian Diebold (Sep 19 2019 at 17:23, on Zulip):

an obvious approach would be to use RA from RLS as a library, for completions, code actions etc.

Florian Diebold (Sep 19 2019 at 17:23, on Zulip):

it might use a lot of memory to run both RA and the compiler in parallel, of course ;)

Igor Matuszewski (Sep 19 2019 at 17:23, on Zulip):

one idea that was hovering around was to use RA as the completion engine in the RLS - you could opt-in into the experimental work and would clearly see more improvements over the existing Racer, while still it being a separate thing

Florian Diebold (Sep 19 2019 at 17:23, on Zulip):

or, the other way around, add the RLS out-of-process compilation to RA

matklad (Sep 19 2019 at 17:24, on Zulip):

Another interesting idea is, from RA side, to lean exclusively on cargo check to get correct error highlighting.

Igor Matuszewski (Sep 19 2019 at 17:24, on Zulip):

wouldn't it kill the main benefit which is latency?

Florian Diebold (Sep 19 2019 at 17:25, on Zulip):

I think the main benefit over racer would be better completions ;)

nikomatsakis (Sep 19 2019 at 17:25, on Zulip):

wouldn't it kill the main benefit which is latency?

well, just for error reporting I guess

Igor Matuszewski (Sep 19 2019 at 17:25, on Zulip):

I meant RLS in RA

Igor Matuszewski (Sep 19 2019 at 17:25, on Zulip):

I think cargo check is sort of good enough now, right? @matklad

matklad (Sep 19 2019 at 17:26, on Zulip):

yeah

Igor Matuszewski (Sep 19 2019 at 17:26, on Zulip):

with obvious pitfall of not being able to use the in-memory text buffers

Igor Matuszewski (Sep 19 2019 at 17:26, on Zulip):

(https://github.com/rust-lang/rust/issues/59976 would be nice to have)

Florian Diebold (Sep 19 2019 at 17:26, on Zulip):

that, and it's only supported in the VSCode plugin, and we can't provide code actions for the fixes provided by rustc (I think?)

nikomatsakis (Sep 19 2019 at 17:26, on Zulip):

so, besides error reporting, RLS today is using save-analysis for things like jump-to-def, right?

matklad (Sep 19 2019 at 17:26, on Zulip):

It lands us in a pretty sweet spot:

matklad (Sep 19 2019 at 17:27, on Zulip):

@Florian Diebold we can provide code actions. In fact, VS Code plugin already implements it

Igor Matuszewski (Sep 19 2019 at 17:27, on Zulip):

@Florian Diebold we translate these fixes in rustc diagnostics to code actions in the RLS

matklad (Sep 19 2019 at 17:27, on Zulip):

but it is 100% true that we should move cargo check from typescript to rust

Igor Matuszewski (Sep 19 2019 at 17:28, on Zulip):

so, besides error reporting, RLS today is using save-analysis for things like jump-to-def, right?

Yeah, RLS uses index for everything except completion

Igor Matuszewski (Sep 19 2019 at 17:28, on Zulip):

if Racer is enabled, we also enable a fallback go-to-def if index doesn't find anything

Igor Matuszewski (Sep 19 2019 at 17:29, on Zulip):

@matklad I guess supporting other build systems becomes a problem but I feel like it's 2018 all over again and it's a non-issue for now (at least in the experimental phase)

matklad (Sep 19 2019 at 17:29, on Zulip):

It lands us in a pretty sweet spot:

There's still a pretty important thing missing in this setup: find usages. You can't use cargo check for find usages, and the feature in rust-analyzer simply does not exist yet :) (and, when we add it, it woun't be precise for a long time)

Igor Matuszewski (Sep 19 2019 at 17:29, on Zulip):

(if we decide to only lean on cargo check, that is)

Igor Matuszewski (Sep 19 2019 at 17:31, on Zulip):

so it's surprising how the critical stuff user wants most of the time is name resolution - that alone gives us jump to def, find all refs (which possibly powers rename) etc.

matklad (Sep 19 2019 at 17:31, on Zulip):

Yeah, the fact that cargo check won't work for facebook is problem though... But I think we can just configure the cargo check command line, so that FB replaces it with buck build?

nikomatsakis (Sep 19 2019 at 17:31, on Zulip):

so, adding cargo check check to r-a doesn't really require anything from the existing RLS infra, except (I guess) maybe the VFS supoprt?

matklad (Sep 19 2019 at 17:31, on Zulip):

@nikomatsakis correct!

Jeremy Kolb (Sep 19 2019 at 17:31, on Zulip):

what does save-analysis give that ra's query infra can't do?

matklad (Sep 19 2019 at 17:32, on Zulip):

correct "find usages" and "rename" are big ones

nikomatsakis (Sep 19 2019 at 17:32, on Zulip):

(it is generated by the compiler, also)

Igor Matuszewski (Sep 19 2019 at 17:32, on Zulip):

(RLS also reimplements the VFS support for rustc for the purposes of out-of-process compilation)

nikomatsakis (Sep 19 2019 at 17:32, on Zulip):

I thought the vision that @Igor Matuszewski painted of "use r-a instead of racer for completions" was interesting. How far is that from "add cargo-check to r-a"?

nikomatsakis (Sep 19 2019 at 17:33, on Zulip):

I guess the main difference is that we'd still be using save-analysis to do things like find all usages etc

Igor Matuszewski (Sep 19 2019 at 17:33, on Zulip):

Yes

Igor Matuszewski (Sep 19 2019 at 17:33, on Zulip):

one immediate concern is that we'd probably duplicate vfs/projet layout detection etc. setup

matklad (Sep 19 2019 at 17:34, on Zulip):

And the vfs itself.

Igor Matuszewski (Sep 19 2019 at 17:34, on Zulip):

@matklad does RA support one-shot queries a la racer? e.g. "complete at line X col Y"

matklad (Sep 19 2019 at 17:34, on Zulip):

Well, it does, but if you don't have a persistent process, that would mean waiting a minute for the initial analysis

Igor Matuszewski (Sep 19 2019 at 17:34, on Zulip):

ah shoot.

Igor Matuszewski (Sep 19 2019 at 17:35, on Zulip):

it'd be good if we juts provide the project layout and the vfs to the RA itself

matklad (Sep 19 2019 at 17:35, on Zulip):

I guess the simplest hack to integrate ra and RLS would be to spin ra process and relay some LSP messages to it :)

matklad (Sep 19 2019 at 17:36, on Zulip):

@Igor Matuszewski you can do that, there's nothing in the core of ra (ra_ide_api crate) that cares about project structure or vfs

matklad (Sep 19 2019 at 17:36, on Zulip):

but the obvious problem is that rls's vfs is not like ra's vfs.

nikomatsakis (Sep 19 2019 at 17:36, on Zulip):

I guess the simplest hack to integrate ra and RLS would be to spin ra process and relay some LSP messages to it :)

lol :)

Igor Matuszewski (Sep 19 2019 at 17:36, on Zulip):

it actually... makes sense in a way :grinning: this would allow us to choose between Racer or RA for the completion engine

matklad (Sep 19 2019 at 17:37, on Zulip):

:thinking: hm, but, if we move to lazy file loading, that would make the two vfses pretty close

Igor Matuszewski (Sep 19 2019 at 17:37, on Zulip):

the user wouldn't have to pay the cost (we'd make it opt-in)

matklad (Sep 19 2019 at 17:37, on Zulip):

@nikomatsakis I am a big fan of just spinning things in another process :D

nikomatsakis (Sep 19 2019 at 17:37, on Zulip):

yeah I mean it's kind of brilliant :)

Igor Matuszewski (Sep 19 2019 at 17:37, on Zulip):

I imagine this would work pretty well - we could use it as a fallback as well

Igor Matuszewski (Sep 19 2019 at 17:38, on Zulip):

the same way we use Racer

nikomatsakis (Sep 19 2019 at 17:38, on Zulip):

it obviously doesn't solve the "2 codebases" scenario

nikomatsakis (Sep 19 2019 at 17:38, on Zulip):

but it's not like anything really will besides further "library-ification" ? I guess maybe we might be able to merge more things (notably VFS)

Igor Matuszewski (Sep 19 2019 at 17:38, on Zulip):

well one idea would be to ship common infrastructure crates like vfs

nikomatsakis (Sep 19 2019 at 17:38, on Zulip):

right, basically "library-ify" those

Igor Matuszewski (Sep 19 2019 at 17:39, on Zulip):

seems like a good direction =)

matklad (Sep 19 2019 at 17:39, on Zulip):

VFS is a hard target for librarification, as the right design is not really well understood

matklad (Sep 19 2019 at 17:40, on Zulip):

it's not that much of code either

matklad (Sep 19 2019 at 17:40, on Zulip):

it might be cool to share the LS protocol implementaiton itself though

matklad (Sep 19 2019 at 17:40, on Zulip):

our is published at https://crates.io/crates/lsp-server

Igor Matuszewski (Sep 19 2019 at 17:41, on Zulip):

I think sharing infrastructure crates like this one is an obvious step in terms of deduplication

matklad (Sep 19 2019 at 17:41, on Zulip):

I feel like the discussion so far makes clear that we don't have a clear understanding where to go... :(

Igor Matuszewski (Sep 19 2019 at 17:41, on Zulip):

question is does it solve the lack of resources problem

nikomatsakis (Sep 19 2019 at 17:43, on Zulip):

can we try to skech into a hackmd the various options we've come up with so far

Igor Matuszewski (Sep 19 2019 at 17:43, on Zulip):

@matklad what is there extra in the vscode extension that RA doesn't have? (like cargo check)

nikomatsakis (Sep 19 2019 at 17:43, on Zulip):

hackmd document

matklad (Sep 19 2019 at 17:44, on Zulip):

@nikomatsakis you are a genius!

nikomatsakis (Sep 19 2019 at 17:44, on Zulip):

I'm going to start going back through the minutes and try to add some notes

nikomatsakis (Sep 19 2019 at 17:44, on Zulip):

you are a genius!

why thank you, I agree

nikomatsakis (Sep 19 2019 at 17:45, on Zulip):

@Igor Matuszewski how hard would it be to have the RLS defer name resolution to rust-analyzer?

Igor Matuszewski (Sep 19 2019 at 17:46, on Zulip):

well now we defer it to rustc, which generates the entire thing RLS relies on

Igor Matuszewski (Sep 19 2019 at 17:46, on Zulip):

do you mean to make it be the backend instead of rustc? I'm not sure I understand

Igor Matuszewski (Sep 19 2019 at 17:47, on Zulip):

do you mean the 'use RA instead of Racer' option?

nikomatsakis (Sep 19 2019 at 17:48, on Zulip):

Right, if I understood, we discussed that in the context of "completions"

nikomatsakis (Sep 19 2019 at 17:48, on Zulip):

but I wasn't clear if that would also be useful for (e.g.) jump-to-def

nikomatsakis (Sep 19 2019 at 17:48, on Zulip):

I guess I'm partly asking "what does RLS use racer for"

Igor Matuszewski (Sep 19 2019 at 17:48, on Zulip):

yes - completions and jump-to-def

Igor Matuszewski (Sep 19 2019 at 17:49, on Zulip):

we could spin up a thread and send LSP requests

Igor Matuszewski (Sep 19 2019 at 17:49, on Zulip):

probably bigger overhead than just setting up Racer in-process but IIUC these are just plumbing issues

Igor Matuszewski (Sep 19 2019 at 17:50, on Zulip):

I can't think of an architectural hurdle we'd need to overcome

nikomatsakis (Sep 19 2019 at 17:52, on Zulip):

ok, there are various notes in the hackmd now

nikomatsakis (Sep 19 2019 at 17:52, on Zulip):

anything missing?

Igor Matuszewski (Sep 19 2019 at 17:52, on Zulip):

/me looking

nikomatsakis (Sep 19 2019 at 17:52, on Zulip):

I don't have a good handle for how complex the second option would really be

nikomatsakis (Sep 19 2019 at 17:53, on Zulip):

I'm also curious about the "external build system" thing --

nikomatsakis (Sep 19 2019 at 17:53, on Zulip):

is this something that RLS today supports at all?

nikomatsakis (Sep 19 2019 at 17:53, on Zulip):

I was under the impression that RLS was pretty tied to cargo

Igor Matuszewski (Sep 19 2019 at 17:54, on Zulip):

yep, thankfully

Igor Matuszewski (Sep 19 2019 at 17:55, on Zulip):

we can get anything that resembles a cargo --build-plan or a set of existing save-analysis files (which now contain invocation information) from which we can derive a build plan

Igor Matuszewski (Sep 19 2019 at 17:56, on Zulip):

I think it doesn't work well with out-of-process compilation though, as it predates that

Igor Matuszewski (Sep 19 2019 at 17:56, on Zulip):

so it'd require a bit of tinkering

nikomatsakis (Sep 19 2019 at 17:56, on Zulip):

basically my fear is this: is trying to combine the two some sort of behemoth that will be unwieldy and turn out to be slow, churn battery power or something, etc?

Igor Matuszewski (Sep 19 2019 at 17:56, on Zulip):

I like the idea of librarification all across the board

Igor Matuszewski (Sep 19 2019 at 17:56, on Zulip):

RLS + RA?

nikomatsakis (Sep 19 2019 at 17:57, on Zulip):

I guess a third alternative is to leave things the way they are but try to find libraries that are worth extracting (I think this is primarily VFS?)

Igor Matuszewski (Sep 19 2019 at 17:57, on Zulip):

I think it'd be pretty fast (in terms of latency), memory in fact might be worse

nikomatsakis (Sep 19 2019 at 17:57, on Zulip):

I mean it seems like it'd have to be worse

nikomatsakis (Sep 19 2019 at 17:57, on Zulip):

we're running rustc and rust-analyzer, right? :)

nikomatsakis (Sep 19 2019 at 17:57, on Zulip):

I guess maybe not worse than cargo check

Igor Matuszewski (Sep 19 2019 at 17:58, on Zulip):

well true

Igor Matuszewski (Sep 19 2019 at 17:58, on Zulip):

I imagine we could reverse the fallback and rely on RA first

matklad (Sep 19 2019 at 17:58, on Zulip):

@nikomatsakis yeah, I think just tying two things together will only make resources problem worse, as changes would need to be coordinated between ra and rls

matklad (Sep 19 2019 at 17:58, on Zulip):

resources = human resources

Igor Matuszewski (Sep 19 2019 at 17:58, on Zulip):

which would bring the reduced latency and missing features from rustc (as find all refs)

matklad (Sep 19 2019 at 17:59, on Zulip):

I am also skeptical about sharing libraries between RLS and rust-analyzer: everything that can be reasonably shared seems pretty thin

matklad (Sep 19 2019 at 17:59, on Zulip):

the biggest thing, the defition of protocol types, is already shared via the crate by Markus Westerlind

nikomatsakis (Sep 19 2019 at 17:59, on Zulip):

right

Igor Matuszewski (Sep 19 2019 at 18:00, on Zulip):

I think it could potentially decrease the area of focus - RA work could focus on experimenting with the frontend

Igor Matuszewski (Sep 19 2019 at 18:00, on Zulip):

whereas if one wants to use RA they could use the same VFS LSP and probably extension if we could somehow move more things into Rust and out of TS

Igor Matuszewski (Sep 19 2019 at 18:00, on Zulip):

I wonder what RLS should focus then, though...

Igor Matuszewski (Sep 19 2019 at 18:00, on Zulip):

bridging into the rustc queries?

matklad (Sep 19 2019 at 18:01, on Zulip):

It seems like we can save resources more by sharing between RLS and rustc (removing save-analysis, which might make things simpler?) and between rust-analyzer and rustc (by sharing actualy "what does Rust code mean" logic)

nikomatsakis (Sep 19 2019 at 18:01, on Zulip):

yeah, that's a third bullet we didn't really dive into much

Igor Matuszewski (Sep 19 2019 at 18:02, on Zulip):

I think removing the save-analysis setup as it is now would be a good step

Igor Matuszewski (Sep 19 2019 at 18:03, on Zulip):

that sort of makes sense - RLS would ask rustc and RA could experiment with different bits of frontend

Igor Matuszewski (Sep 19 2019 at 18:03, on Zulip):

hopefully RLS transition could be a one-off thing and we could all focus on the RA/frontend bits =)

nikomatsakis (Sep 19 2019 at 18:04, on Zulip):

I think removing the save-analysis setup as it is now would be a good step

I'm not 100% sure what it would be replaced with, but I gotta run I think

nikomatsakis (Sep 19 2019 at 18:04, on Zulip):

maybe we want to discuss more another time?

nikomatsakis (Sep 19 2019 at 18:04, on Zulip):

(or you all can continue, I'll catch up)

matklad (Sep 19 2019 at 18:04, on Zulip):

I think it makes sense to take a pause and edit that shared markdown document

matklad (Sep 19 2019 at 18:04, on Zulip):

@Igor Matuszewski could you add something to it about why we want to move off save analysis.

Igor Matuszewski (Sep 19 2019 at 18:05, on Zulip):

yeah, will do

matklad (Sep 19 2019 at 18:05, on Zulip):

?

Igor Matuszewski (Sep 19 2019 at 18:05, on Zulip):

er, sorry

Igor Matuszewski (Sep 19 2019 at 18:05, on Zulip):

you mean here?

Igor Matuszewski (Sep 19 2019 at 18:05, on Zulip):

(thought you mean the doc :p)

Igor Matuszewski (Sep 19 2019 at 18:06, on Zulip):

so technically the reason we used save-analysis in the first place is because the infra setup was in its infancy and we wanted a working solution then

Igor Matuszewski (Sep 19 2019 at 18:07, on Zulip):

incremental does help but many times we redo the entire analysis continuously, as user happily types away

matklad (Sep 19 2019 at 18:07, on Zulip):

nope, in the doc

nikomatsakis (Sep 19 2019 at 18:07, on Zulip):

I think @matklad did mean the doc :)

Igor Matuszewski (Sep 19 2019 at 18:07, on Zulip):

:sad:

Igor Matuszewski (Sep 19 2019 at 18:08, on Zulip):

will do, give me a sec

matklad (Sep 19 2019 at 18:13, on Zulip):

@Igor Matuszewski but I'll will answer you here :-)

I agree that save-analysis is just a fundamentally wrong thing for IDEs, so, if we want to maintain RLS, we should probably move off it for this reason.

At the same time, I feel like save-analysis is a pretty important thing for use-cases other than IDEs. Like, being able to dump all that compiler knows about a crate into JSON and then process it with some other tool is a cool use-case. In particular, I feel that cargo-src project might be underused. I also feel like save-analysis might be the right approach for rustdoc 2.0. However, if right now nobody besides RLS uses it, it doesn't make much sense to maintain it.

Igor Matuszewski (Sep 19 2019 at 18:17, on Zulip):

@matklad we talked about this a bit and I agree =) it's hard to marry it to a single data format, as different tools want different data (cargo src, rustdoc 2.0, callgraph generating tools etc.) so maybe a more stable way to query these things might be more appropriate

Igor Matuszewski (Sep 19 2019 at 18:18, on Zulip):

(then there is a question how stable it is so rustc doesn't need to worry about back-compat that much)

Last update: Nov 20 2019 at 01:10UTC