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

Topic: lowering


nikomatsakis (Mar 13 2019 at 19:00, on Zulip):

so @scalexm, I've not gotten as far on this as I liked, because I was running late on other things, but I'm looking a bit

nikomatsakis (Mar 13 2019 at 19:00, on Zulip):

so far I mostly added some comments here and there ;)

nikomatsakis (Mar 13 2019 at 19:03, on Zulip):

oh dear, we should also bump up to a recent version of salsa

scalexm (Mar 13 2019 at 19:03, on Zulip):

@nikomatsakis where did you write those comments actually?

nikomatsakis (Mar 13 2019 at 19:04, on Zulip):

see the most recent commit in https://github.com/nikomatsakis/chalk-ndm/tree/query-driven-lowering

nikomatsakis (Mar 13 2019 at 19:12, on Zulip):

so @tmandry already set up a number of queries here

nikomatsakis (Mar 13 2019 at 19:14, on Zulip):
nikomatsakis (Mar 13 2019 at 19:15, on Zulip):

this setup isn't quite right since, in the future, I would expect specialization priorities to be needed in order to compute the lowered rules

nikomatsakis (Mar 13 2019 at 19:15, on Zulip):

the actual lowering into IR is done in the environment method

nikomatsakis (Mar 13 2019 at 19:17, on Zulip):

as an aside, I suspect we can remove the logic here around the derefs trait for now

nikomatsakis (Mar 13 2019 at 19:17, on Zulip):

we might want it later, once we make some progress on encoding coercions, but...

scalexm (Mar 13 2019 at 19:18, on Zulip):

I'm ok for removing the logic around derefs trait

scalexm (Mar 13 2019 at 19:19, on Zulip):

we may probably want to also do that for unselected projections, which are broken atm

nikomatsakis (Mar 13 2019 at 19:19, on Zulip):

so, I think we probably want environment to take some kind of indication of which rules it is generating

nikomatsakis (Mar 13 2019 at 19:19, on Zulip):

we may probably want to do that for unselected projections, which are broken atm

do what?

scalexm (Mar 13 2019 at 19:19, on Zulip):

remove some logic around them :)

nikomatsakis (Mar 13 2019 at 19:19, on Zulip):

e.g., maybe it should be environment(TraitId)

nikomatsakis (Mar 13 2019 at 19:19, on Zulip):

remove some logic around them :)

ah :) yeah, perhaps. I think we're going to want that concept pretty soon but it'd be ok to add it back

nikomatsakis (Mar 13 2019 at 19:20, on Zulip):

implied bounds make things a bit complicated

nikomatsakis (Mar 13 2019 at 19:20, on Zulip):

well, I guess this is not dissimilar from the logic we had in rustc

scalexm (Mar 13 2019 at 19:22, on Zulip):

ah yeah so probably environment(ItemId) or something then

scalexm (Mar 13 2019 at 19:22, on Zulip):

so that we cover impls as well etc?

scalexm (Mar 13 2019 at 19:23, on Zulip):

then we can indeed have a similar setup to what is done in rustc, with some program_clauses_for_... (including for environment)

nikomatsakis (Mar 13 2019 at 19:24, on Zulip):

yeah, sorry, got distracted.

nikomatsakis (Mar 13 2019 at 19:24, on Zulip):

I mean the thing is, we definitely need to be able to ask "give me the rules that can prove Implemented[SomeTrait]"

nikomatsakis (Mar 13 2019 at 19:25, on Zulip):

i.e., specialization will need it

nikomatsakis (Mar 13 2019 at 19:25, on Zulip):

well just everything

nikomatsakis (Mar 13 2019 at 19:25, on Zulip):

what I think we want then is that this would not be a method on a rust_ir::Program

nikomatsakis (Mar 13 2019 at 19:26, on Zulip):

but rather a query on the salsa database

nikomatsakis (Mar 13 2019 at 19:26, on Zulip):

and it would invoke other queries to extract out the data it needs from the rust-ir

nikomatsakis (Mar 13 2019 at 19:26, on Zulip):

ah, right, I remember now

nikomatsakis (Mar 13 2019 at 19:26, on Zulip):

for implied bounds, the key point is that we only need those rules when given FromEnv,

nikomatsakis (Mar 13 2019 at 19:26, on Zulip):

and we can kind of derive it by going forward from what's in the environment, right?

scalexm (Mar 13 2019 at 19:27, on Zulip):

right, that's what is done in the program_clauses_for_environment query in rustc

nikomatsakis (Mar 13 2019 at 19:27, on Zulip):

yeah, I remember thinking about this, I just forgot the answer that we found :)

nikomatsakis (Mar 13 2019 at 19:27, on Zulip):

ok, so it seems like we kind of want to move a variant (hopefully nicer) of that logic from rustc into chalk

nikomatsakis (Mar 13 2019 at 19:27, on Zulip):

makes sense

scalexm (Mar 13 2019 at 19:30, on Zulip):

so if I understand well, regarding RLS integration, these queries in chalk which e.g. compute an environment would call some other queries e.g. lower_type which would compute the rust-ir representation of a given type, but these lower queries may be implemented in another crate like in the RLS crate?

nikomatsakis (Mar 13 2019 at 19:31, on Zulip):

right

nikomatsakis (Mar 13 2019 at 19:31, on Zulip):

so I think the steps here would be as follows

nikomatsakis (Mar 13 2019 at 19:31, on Zulip):

first, we make the queries in question, all in the one crate (chalk)

nikomatsakis (Mar 13 2019 at 19:31, on Zulip):

then we can extract the lowering queries into another crate (let's call it chalk_lower)

nikomatsakis (Mar 13 2019 at 19:31, on Zulip):

but leave behind the ones that provide the rust-ir

nikomatsakis (Mar 13 2019 at 19:32, on Zulip):

so if you have layers, it's like:

nikomatsakis (Mar 13 2019 at 19:32, on Zulip):

the "shim" part would be a trait that we define

nikomatsakis (Mar 13 2019 at 19:32, on Zulip):

i.e.,

trait RustIrShim {
    fn rust_ir_struct(Id) -> rust_ir::StructDatum;
}
nikomatsakis (Mar 13 2019 at 19:33, on Zulip):

we can then implement this trait like so in the chalk crate

impl RustIrShim for ChalkDatabase {
    fn rust_ir_struct(&self, id: Id) -> StructDatum {
        self.rust_ir_query(id)
    }
}
nikomatsakis (Mar 13 2019 at 19:33, on Zulip):

not sure if that makes sense, not sure how familiar you are with salsa's setup

scalexm (Mar 13 2019 at 19:33, on Zulip):

I'm not that familiar but that makes sense

nikomatsakis (Mar 13 2019 at 19:34, on Zulip):

should be straightforward

nikomatsakis (Mar 13 2019 at 19:34, on Zulip):

once we get the queries setup correctly

nikomatsakis (Mar 13 2019 at 19:34, on Zulip):

which is cool, btw, I'm happy with how that part of salsa's design is working out :)

nikomatsakis (Mar 13 2019 at 19:34, on Zulip):

for some reason, however, upgrading to salsa 0.10.0 is not building for me

scalexm (Mar 13 2019 at 19:40, on Zulip):

in rust_ir/lowering.rs, we use that Env<'k> to resolve things like type parameters

scalexm (Mar 13 2019 at 19:41, on Zulip):

so this would now be an input to the rust-ir queries I guess

scalexm (Mar 13 2019 at 19:46, on Zulip):

mmh we could actually have two levels: the top level-query for example lower_impl which would start with an empty env, and then which would call some lowering functions without passing through the salsa database, building that Env<'k> along the way

scalexm (Mar 17 2019 at 20:42, on Zulip):

@nikomatsakis it would be cool if we were not using String as an error type in the salsa queries; I'm currently trying to convert all error types to real ones (be it custom enum or struct) that do implement Clone

Jake Goulding (Mar 17 2019 at 20:59, on Zulip):

@scalexm as shameless self-promotion, may I suggest giving my new SNAFU crate a whirl? :angel:

scalexm (Mar 18 2019 at 12:13, on Zulip):

@Jake Goulding lol I’ll give it a try

Last update: Nov 15 2019 at 09:40UTC