Stream: t-compiler/wg-rls-2.0/chalk

Topic: update

nikomatsakis (Apr 09 2019 at 20:38, on Zulip):

BTW, things slowed down a bit here for a few reasons, but I wanted to give a few updates.

1. Part of the reason for the slowdown is that (on the wg-traits side) we were looking against rustc-chalk integration. I still think though we should be pursuing the RLS 2.0 integration. A lot of the hard problems though will be the same in both cases.
2. That said, I spent a fair amount of time refactoring chalk to enable "query-ification" and I plan to open some PRs for that soon. It's not all the way done but at least the path is becoming clear.

Florian Diebold (Apr 09 2019 at 20:50, on Zulip):

I've actually been working on preparing for Chalk integration on the rust-analyzer side (see also rust-analyzer#1120), so I hope we'll be ready to do it once the Chalk queryfication is done :)

nikomatsakis (Apr 10 2019 at 09:34, on Zulip):

@Florian Diebold great! I was planning on creating a doodle today to find a time to discuss the queries and setup in more depth. Maybe you can talk about what you've been doing as well so we can line them up.

nikomatsakis (Apr 10 2019 at 09:34, on Zulip):

And/or feel free to leave some notes here now :)

nikomatsakis (Apr 10 2019 at 09:34, on Zulip):

One thing that became clear btw, when @Sunjay Varma and I were looking, is that the notion of "current crate" does not want to completely go away

nikomatsakis (Apr 10 2019 at 09:35, on Zulip):

I think the way this will map to rust-analyzer is that there needs to be a distinct "trait solver" for each crate -- this is because each crate operates with a different set of impls

nikomatsakis (Apr 10 2019 at 09:35, on Zulip):

basically, I think the rust-analyzer has no notion of current crate, and that's fine, but chalk does, and so rust analyzer will always talk to chalk with a current crate in mind

Florian Diebold (Apr 10 2019 at 09:41, on Zulip):

hm yeah, that's true

matklad (Apr 10 2019 at 10:00, on Zulip):

That makes total sense, yeah. Question: would solvers for different crates share any data?

For example, each crate depends on std, so each solver has to know about all of std's impls. If we naively duplicate the impls per solver, we'll have O(N^2) situation

nikomatsakis (Apr 10 2019 at 10:00, on Zulip):

I've been wondering about that. I'm not sure the answer.

nikomatsakis (Apr 10 2019 at 10:02, on Zulip):

I think initially they would share minimal state, but we might be able to increase it.

nikomatsakis (Apr 10 2019 at 10:02, on Zulip):

That said, my hope would be that we aren't (e.g.) type-checking other crates that often :)

nikomatsakis (Apr 10 2019 at 10:03, on Zulip):

So it may not be a big issue in practice

Florian Diebold (Apr 10 2019 at 12:55, on Zulip):

We'd at least be type-checking all the crates in the workspace, which may already be a few... but we'll see :)

Last update: Nov 15 2019 at 09:40UTC