Stream: wg-traits

Topic: chalk crates


nikomatsakis (Apr 16 2019 at 12:19, on Zulip):

So I was thinking over what @matklad wrote and I have a proposal for a simpler organization of the crates -- but to start, I filed https://github.com/rust-lang/chalk/issues/212 -- I thought @detrumi you might be interested in this as a "starter refactoring".

detrumi (Apr 16 2019 at 12:24, on Zulip):

Yeah sounds good. Coinductive traits sound a bit scary, but I see that they're documented in rustc-guide, so that helps :slight_smile:

nikomatsakis (Apr 16 2019 at 13:22, on Zulip):

Heh, I've yet to find anyone who really claims to understand coinduction ;)

nikomatsakis (Apr 16 2019 at 17:56, on Zulip):

heh, @detrumi, you're fast https://github.com/rust-lang/chalk/pull/213 :)

nikomatsakis (Apr 16 2019 at 17:56, on Zulip):

I'm hoping to create some follow-up plans tonight

detrumi (Apr 16 2019 at 18:00, on Zulip):

You mentioned it would be straightforward, but I didn't expect it to be that easy

nikomatsakis (Apr 16 2019 at 18:26, on Zulip):

Just a softball ;)

nikomatsakis (Apr 16 2019 at 18:33, on Zulip):

OK, I started writing up https://github.com/rust-lang/chalk/issues/214 but I didn't finish

nikomatsakis (Apr 16 2019 at 18:33, on Zulip):

will do a bit more later

matklad (Apr 16 2019 at 18:36, on Zulip):

@nikomatsakis am I correct that the chalk crate is actually a test harness for chalk? Would it be a good idea to rename it to chalk-tester, and have the public API crate named just chalk?

nikomatsakis (Apr 16 2019 at 18:36, on Zulip):

Probably, yes

nikomatsakis (Apr 16 2019 at 19:38, on Zulip):

Ok I finished my write-up in https://github.com/rust-lang/chalk/issues/214 (cc @matklad, @scalexm, @tmandry -- not sure who else). I'm not sure how clear it is, though, and the final set of steps are in particular incomplete. This is because I am wondering. Maybe it makes sense, at least for now, to collapse chalk-solve and chalk-rules into one crate. This would simplify things somewhat, and might make the transition a bit easier too. At least there would be fewer crates and intermediaries.

The main value I see in separating out the chalk-rules code is that we might be able to reuse it from rustc, with a bit more refactoring. But I'm not sure if that's a very good goal. Maybe it's better to shoot for having rustc (and chalk) share chalk-ir, so it can reuse the whole solver infrastructure, which would really be ideal (this is what I expect the RLS to do).

Moreover, it might be worth collapsing them for now and then trying to tease them apart only if we later want rustc to reuse the chalk-rules code but not chalk-ir.

nikomatsakis (Apr 16 2019 at 19:55, on Zulip):

The more I think about it, the more I think I should rewrite that, but with the perspective of merging chalk-solve and chalk-rules for now

nikomatsakis (Apr 16 2019 at 19:56, on Zulip):

I think it would make things mildly easier and we can always tease them apart again

matklad (Apr 16 2019 at 19:59, on Zulip):

Don't really have a lot of context here, but, if integrating with rls is far easier than with rustc, it makes sense to merge, integrate in rls, and then tease apart, informed by the integration experience.

matklad (Apr 16 2019 at 19:59, on Zulip):

/me really just wants cool completions in rust-analyzer :D

nikomatsakis (Apr 16 2019 at 21:35, on Zulip):

If we merge the two crates into one, I think the steps would be roughly like this:

nikomatsakis (Apr 16 2019 at 21:35, on Zulip):

This is mildly easier than the other way because the chalk-rules code can require ChalkSolveDatabase

nikomatsakis (Apr 16 2019 at 21:35, on Zulip):

But I suppose it's not really all that different

varkor (Apr 16 2019 at 21:37, on Zulip):

Coinductive traits sound a bit scary

I wonder if "coinductive trait" is a bit of a misnomer, as there doesn't seem to be anything (co)inductive about traits at all

varkor (Apr 16 2019 at 21:38, on Zulip):

it's really the auto bounds that are checked corecursively

varkor (Apr 16 2019 at 21:39, on Zulip):

(I'm not sure where the naming came from initially, so maybe there's another reason behind it)

nikomatsakis (Apr 16 2019 at 21:40, on Zulip):

I confess I had not heard the term corecursive before

nikomatsakis (Apr 16 2019 at 21:40, on Zulip):

I think there are other ways to think about auto traits, but from what I understand of co-induction, it seems like a reasonably good fit

varkor (Apr 16 2019 at 21:40, on Zulip):

I think the terms recursion/induction are often used in very similar contexts anyway

nikomatsakis (Apr 16 2019 at 21:41, on Zulip):

Still, this would probably be a useful topic to discuss more deeply! (Though in a separate zulip topic, perhaps)

varkor (Apr 16 2019 at 21:42, on Zulip):

(I think that one wouldn't call a normal trait "inductive", which is analogous to calling an auto trait "coinductive")

varkor (Apr 16 2019 at 21:42, on Zulip):

(but that's a tangential line of thought anyway :slight_smile: )

nikomatsakis (Apr 16 2019 at 21:52, on Zulip):

OK, I updated chalk#214 to a simpler proposal, including some implementation steps. @detrumi -- take a look, maybe you want to take that on?

nikomatsakis (Apr 16 2019 at 21:52, on Zulip):

Gotta run for the time being

detrumi (Apr 17 2019 at 05:41, on Zulip):

For implementing is_coinductivedirectly in chalk-solve (assuming you mean is_coinductive_trait), would that become a method on Program then?

nikomatsakis (Apr 17 2019 at 09:26, on Zulip):

@detrumi ah, yeah, I wasn't very specific about that. It should not be a method on Program, as chalk-solve has no access to Program. Rather, we would modify this call here and inline the definition

detrumi (Apr 17 2019 at 09:29, on Zulip):

But inlining will also call db.program_ir()to get the Program, right?

nikomatsakis (Apr 17 2019 at 09:32, on Zulip):

No

nikomatsakis (Apr 17 2019 at 09:32, on Zulip):

it should just call db.trait_datum()

nikomatsakis (Apr 17 2019 at 09:32, on Zulip):

since db will now implement RustIrSource

detrumi (Apr 17 2019 at 09:33, on Zulip):

Ah, of course

detrumi (Apr 18 2019 at 20:06, on Zulip):

Looking into rustc's ChalkInferenceContext::program_clauses_impl , I can see that FromEnv goals might be tricky, as they come from the environment

nikomatsakis (Apr 18 2019 at 20:25, on Zulip):

@detrumi yes, but we should have the info we need

nikomatsakis (Apr 18 2019 at 20:25, on Zulip):

@detrumi note that I had intended for that bit to be a separate PR

nikomatsakis (Apr 18 2019 at 20:25, on Zulip):

though I may not have made that very clear :)

nikomatsakis (Apr 18 2019 at 20:25, on Zulip):

i.e., I'd rather land the other changes and leave that one on its own

nikomatsakis (Apr 18 2019 at 20:25, on Zulip):

as it's more complex

nikomatsakis (Apr 19 2019 at 15:08, on Zulip):

@detrumi left a tiny nit, but other than that, I think this PR is ready to land, yeah?

detrumi (Apr 19 2019 at 15:55, on Zulip):

Yes, should be ready to go!

nikomatsakis (Apr 19 2019 at 18:53, on Zulip):

Looking into rustc's ChalkInferenceContext::program_clauses_impl , I can see that FromEnv goals might be tricky, as they come from the environment

Do you feel like you understand what is going on here, @detrumi?

nikomatsakis (Apr 19 2019 at 18:54, on Zulip):

If it would be helpful, I think either @scalexm or I could provide more details

nikomatsakis (Apr 19 2019 at 18:54, on Zulip):

PS, I merged your PR, very nice work.

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

(Also, @scalexm, I'm assuming you don't object to the simplified crate hierarchy I proposed)

scalexm (Apr 19 2019 at 19:22, on Zulip):

@nikomatsakis no objection apart from thinking it is a good thing

detrumi (Apr 19 2019 at 19:22, on Zulip):

@nikomatsakis Well, I understand what these functions are doing at a high level, and it's not too difficult to port the big match on the goal. But for some of the details it feels more like guessing than really understanding it

nikomatsakis (Apr 19 2019 at 19:23, on Zulip):

as I recall, we were half-guessing when we wrote it ;)

detrumi (Apr 19 2019 at 19:23, on Zulip):

Like, I have no idea what the clause categories are in the rustc code, or what role the WellFormed checks play

nikomatsakis (Apr 19 2019 at 19:23, on Zulip):

I think it's simple enough except for the environment case

nikomatsakis (Apr 19 2019 at 19:24, on Zulip):

This is tied in with "implied bounds", I'm not sure if that's a phrase you're familiar with?

detrumi (Apr 19 2019 at 19:26, on Zulip):

I am now :slight_smile: yeah that sounds logical, doesn't surprise me that there's some bounds that aren't explicitly stated

detrumi (Apr 19 2019 at 19:28, on Zulip):

as I recall, we were half-guessing when we wrote it ;)

I'm often translating the rustc code just by looking at the types and seeing where I can plug in things, but maybe that's good enough in this case

nikomatsakis (Apr 19 2019 at 19:29, on Zulip):

the idea is something like this though

detrumi (Apr 19 2019 at 19:30, on Zulip):

One thing that's also not clear yet is where this code will end up in Chalk, at the moment I'm still working in the program_clauses_that_could_match function, and just not using self.environment()

nikomatsakis (Apr 19 2019 at 19:30, on Zulip):
trait Foo: Bar { }
trait Bar: Baz { }
nikomatsakis (Apr 19 2019 at 19:30, on Zulip):

if you know have where T: Foo, you also know that T: Bar (and T: Baz)

nikomatsakis (Apr 19 2019 at 19:30, on Zulip):

so the loop is kind of elaborating those things

nikomatsakis (Apr 19 2019 at 19:30, on Zulip):

I don't remember precisely but that's the general context

detrumi (Apr 19 2019 at 19:31, on Zulip):

what loop are we talking about?

nikomatsakis (Apr 19 2019 at 19:31, on Zulip):

heh, good question. The last time I went looking for it I remember it took me a while to find it.

nikomatsakis (Apr 19 2019 at 19:32, on Zulip):

One thing that's also not clear yet is where this code will end up in Chalk, at the moment I'm still working in the program_clauses_that_could_match function, and just not using self.environment()

this seems like a good way to start

detrumi (Apr 19 2019 at 19:32, on Zulip):

Haven't looked yet, but the point is that there's a place where more clauses are added to the environment, right?

nikomatsakis (Apr 19 2019 at 19:34, on Zulip):

heh, good question. The last time I went looking for it I remember it took me a while to find it.

ok so the main code is here, the program_clauses_impl fn

nikomatsakis (Apr 19 2019 at 19:34, on Zulip):

however, it includes an innocuous looking line at the end

nikomatsakis (Apr 19 2019 at 19:34, on Zulip):
 let env_clauses = self.infcx.tcx.program_clauses_for_env(canonical_environment);
nikomatsakis (Apr 19 2019 at 19:35, on Zulip):

that function is here

detrumi (Apr 19 2019 at 19:35, on Zulip):

Ah, I see a while !last_round.is_empty() loop with a visitor

nikomatsakis (Apr 19 2019 at 19:35, on Zulip):

Yes.

nikomatsakis (Apr 19 2019 at 19:35, on Zulip):

As an aside, we really should have written more docs on these functions :)

nikomatsakis (Apr 19 2019 at 19:36, on Zulip):

but this is an example of the code I was talking about above

scalexm (Apr 19 2019 at 19:36, on Zulip):

Well, the doc is basically @nikomatsakis and I :p

nikomatsakis (Apr 19 2019 at 19:36, on Zulip):

i.e., we look in the environment --- if we see FromEnv(T: Foo), that means there is an in-scope where clause for T: Foo. In that case, we fetch the definition of Foo and add some of its clauses in there

nikomatsakis (Apr 19 2019 at 19:37, on Zulip):

so in the next round we would find FromEnv(T: Bar) in the list, which would cause us to cover Baz

nikomatsakis (Apr 19 2019 at 19:37, on Zulip):

and so forth

detrumi (Apr 19 2019 at 19:37, on Zulip):

Well, the doc is basically nikomatsakis and I :p

Can I read you like a book, too?

nikomatsakis (Apr 19 2019 at 19:37, on Zulip):

there can be cycles here so we run until a fixed point

detrumi (Apr 19 2019 at 19:38, on Zulip):

Ah ok, that's actually not too bad

detrumi (Apr 19 2019 at 19:39, on Zulip):

At least, the complexity of it. Getting the ordering to be similar might be difficult

nikomatsakis (Apr 19 2019 at 19:39, on Zulip):

The ordering?

nikomatsakis (Apr 19 2019 at 19:39, on Zulip):

It shouldn't really matter what order

nikomatsakis (Apr 19 2019 at 19:40, on Zulip):

We are returning a vec, but the order of things in the vec are not that important

detrumi (Apr 19 2019 at 19:40, on Zulip):

I meant visiting order, or doesn't that make a difference?

nikomatsakis (Apr 19 2019 at 19:41, on Zulip):

I don't think that should matter

detrumi (Apr 19 2019 at 19:41, on Zulip):

Ok, never mind then

detrumi (Apr 19 2019 at 19:51, on Zulip):

Thanks for the pointers, this gave me some confidence that I'm going the right way (and some context for the env part)

Florian Diebold (Apr 20 2019 at 15:06, on Zulip):

Is canonicalization accessible outside of chalk_solve? all ways of canonicalizing seem to be pub(crate), except for GoalExt which is "Useful for REPLs and tests but not much else".

detrumi (Apr 21 2019 at 20:17, on Zulip):

I've ported most of the env stuff over now, the tricky part is the type matches, since the variants don't match up. Very WIP PR: https://github.com/rust-lang/chalk/pull/216

detrumi (Apr 24 2019 at 07:57, on Zulip):

Rustc's program_clauses_impl does some filtering on clause.category() == ProgramClauseCategory::WellFormed, is there a Chalk-equivalent or does that need to be introduced?

detrumi (Apr 24 2019 at 07:58, on Zulip):

(most tests are failing on "trait impl for ... does not meet well-formedness requirements")

detrumi (Apr 24 2019 at 08:02, on Zulip):

Ah, missed the comments above to_program_clauses, so if I understand correctly, the relevant clauses are wrapped in WellFormed instead

nikomatsakis (Apr 25 2019 at 09:43, on Zulip):

@detrumi I was perusing your PR as I drank my morning coffee :coffee: and I left some more notes here -- make sense?

One thing I was wondering is how familiar you are with the clause lowering -- i.e., do you understand roughly the logic behind what these functions are doing? I'm not clear on how well this part of the picture has been explained.

nikomatsakis (Apr 25 2019 at 09:45, on Zulip):

(Also, independently, I realized something as I was reading this over -- once we complete this work, I suspect we're going to want to do a bit more refactoring to introduce salsa here, so that we can plausibly have some caching. But this would be more of an optimization -- and it might make sense to push more on the RLS integration before doing it.)

detrumi (Apr 25 2019 at 12:57, on Zulip):

Great feedback! I actually also thought about doing the retain, but decided against it in case it was set up that way for performance reasons. But it makes sense to just simplify it

detrumi (Apr 25 2019 at 13:00, on Zulip):

One thing I was wondering is how familiar you are with the clause lowering -- i.e., do you understand roughly the logic behind what these functions are doing? I'm not clear on how well this part of the picture has been explained.

I must confess that some parts were translated by a mostly mechanical process of looking at the matched types and figuring out what the code is doing exactly. So there's probably some code there that's just plain wrong, and indeed I need to understand it a bit better.

detrumi (Apr 25 2019 at 14:51, on Zulip):

Ah, that's not very useful. let me try to write down my current understanding of the code, so that you can point out where my understanding is wrong/lacking

detrumi (Apr 25 2019 at 15:05, on Zulip):

The term lowering is already confusing, since it can mean both lowering AST to rust-ir, and rust-ir to logical rules (ProgramClauses, the one we're dealing with here)

detrumi (Apr 25 2019 at 15:09, on Zulip):

Ah I understand now, so both the database and the goal are talking about rust-ir, and we want to lower them both to logical rules to match them.

detrumi (Apr 25 2019 at 15:10, on Zulip):

Question: why can't we lower the goal itself first?

detrumi (Apr 25 2019 at 15:35, on Zulip):

As for the lowering itself: all the matching functions do in the end is just call the to_program_clauses for the ProgramClauses the goal is pointing at

nikomatsakis (Apr 25 2019 at 15:48, on Zulip):

The term lowering is already confusing, since it can mean both lowering AST to rust-ir, and rust-ir to logical rules (ProgramClauses, the one we're dealing with here)

well, lowering is just a general term for converting from one IR to another -- typically converting from some "high-level" IR to a more "low-level" IR

nikomatsakis (Apr 25 2019 at 15:48, on Zulip):

Question: why can't we lower the goal itself first?

the goal is .. lowered in some sense

nikomatsakis (Apr 25 2019 at 15:48, on Zulip):

in rust, you don't have explicit goals like "well-formed" or what have you

nikomatsakis (Apr 25 2019 at 15:49, on Zulip):

but basically we have these rules for converting bits of rust-ir into program clauses

nikomatsakis (Apr 25 2019 at 15:49, on Zulip):

each of those clauses can be used to prove some particular kind of domain-goal

nikomatsakis (Apr 25 2019 at 15:49, on Zulip):

so e.g. impl Foo for Bar generates a Implemented(Bar: Foo) :- ... clause

nikomatsakis (Apr 25 2019 at 15:50, on Zulip):

so what this code is doing is looking at the thing we have to prove and figuring out whihc bits of rust-ir might contribute a clause that could be useful

detrumi (Apr 25 2019 at 15:50, on Zulip):

Right

nikomatsakis (Apr 25 2019 at 15:50, on Zulip):

(the old code just lowered everything first, but we're trying to be more selective)

nikomatsakis (Apr 25 2019 at 15:51, on Zulip):

the specifics of how the code works, then, comes from taking a look at the actual rules and just trying to figure it out

detrumi (Apr 25 2019 at 15:59, on Zulip):

So why does Chalk's DomainGoal have so many more variants than rustc's? Is it because rustc computes more stuff on the side, while Chalk explicitly stores it inside the goal?

nikomatsakis (Apr 25 2019 at 16:14, on Zulip):

Chalk's domain goal includes some experiments that we've not yet tried to integrate into rustc

nikomatsakis (Apr 25 2019 at 16:14, on Zulip):

Nor fully finished, really

nikomatsakis (Apr 25 2019 at 16:14, on Zulip):

We also model things (like coherence) that rustc doesn't yet model

nikomatsakis (Apr 25 2019 at 16:14, on Zulip):

Which requires some new sorts of domain goals

detrumi (Apr 27 2019 at 20:43, on Zulip):

Hmm, so I'm trying to figure out why some of the tests are failing. Take the fundamental_types test for example:

goal { forall < T > { not { IsLocal ( Box < T > ) } } }
using solver: SLG { max_size: 10 }
expected:
No possible solution
actual:
Unique; substitution [], lifetime constraints []

Details aside, I'm a bit confused as to why it's finding more solutions.
The logic for checking whether it's local and such should be done in to_program_clauses.
But calling to_program_clauses on too many things should only give less solutions, not more, right?
If so, could this be an uncovered problem in to_program_clauses?

detrumi (Apr 27 2019 at 20:48, on Zulip):

Ah, or maybe it's missing some clauses instead, and that's why there's more solutions

nikomatsakis (Apr 28 2019 at 09:33, on Zulip):

But calling to_program_clauses on too many things should only give less solutions, not more, right?
If so, could this be an uncovered problem in to_program_clauses?

not necessarily, because of negative logic

detrumi (Apr 28 2019 at 19:56, on Zulip):

That's weird, the environment seems to be empty...

detrumi (Apr 28 2019 at 20:02, on Zulip):

Ah yes, the old code was calling the environment() function in query.rs, and the environment.clauses that is used now in the program_clauses function is empty

detrumi (Apr 28 2019 at 20:03, on Zulip):

No wonder tests are failing, if env clauses like IsLocal(Local) are missing

nikomatsakis (Apr 29 2019 at 16:56, on Zulip):

Hey @detrumi -- I'm wondering, would you like help with the "last mile" in chalk#216?

nikomatsakis (Apr 29 2019 at 16:57, on Zulip):

i.e., I was considering checking it out and pushing some commits, but didn't want to step on your toes

detrumi (Apr 29 2019 at 17:42, on Zulip):

@nikomatsakis Yes, feel free to. I was a bit stuck on the environment stuff anyways, since that requires more knowledge of the high-level design

detrumi (Apr 29 2019 at 17:45, on Zulip):

And since this might be blocking rls2 integration, you working on it will help speed it up a bit (especially because the PR grew a bit in size)

nikomatsakis (Apr 29 2019 at 20:26, on Zulip):

I've been fixing some of these cases FYI

nikomatsakis (Apr 29 2019 at 20:26, on Zulip):

I just hit an interesting case (cc @scalexm) --

nikomatsakis (Apr 29 2019 at 20:27, on Zulip):

in particular if you have a goal like ?T: Send, and this is an auto-trait, we need to enumerate all structs to find the rules

nikomatsakis (Apr 29 2019 at 20:27, on Zulip):

I guess not that interesting

nikomatsakis (Apr 29 2019 at 20:27, on Zulip):

for now I think I will add the helpers to do that, but also a FIXME to address this better with 'non-enumerable' goals

nikomatsakis (Apr 29 2019 at 20:46, on Zulip):

OK, we're down to these errors

failures:
    test::coherence::downstream_impl_of_fundamental_43355
    test::coherence::fundamental_traits
    test::coherence::two_blanket_impls_open_ended
    test::fundamental_types
    test::gat_implied_bounds
    test::slg::cached_answers_1
    test::slg::cached_answers_2
    test::slg::cached_answers_3
    test::slg::contradiction
    test::slg::example_2_1_EWFS
    test::slg::example_2_2_EWFS
    test::slg::example_2_3_EWFS
    test::slg::example_3_3_EWFS
    test::slg::negative_answer_delayed_literal
    test::slg::negative_loop
    test::unselected_projection_with_gat
nikomatsakis (Apr 29 2019 at 20:46, on Zulip):

I didn't try to look into coherence yet

nikomatsakis (Apr 29 2019 at 20:47, on Zulip):

Oh, I bet I know what the slg* errors are

nikomatsakis (Apr 29 2019 at 20:50, on Zulip):

OK, down to

failures:
    test::coherence::downstream_impl_of_fundamental_43355
    test::coherence::fundamental_traits
    test::coherence::two_blanket_impls_open_ended
    test::fundamental_types
    test::gat_implied_bounds
    test::slg::example_3_3_EWFS
    test::unselected_projection_with_gat
detrumi (Apr 30 2019 at 07:32, on Zulip):

Ah cool, didn't know of PolarizedTraitRef

nikomatsakis (Apr 30 2019 at 09:46, on Zulip):

@detrumi ok, tests pass now at least. Really makes me wonder if we could find a more automated way to do this. =)

detrumi (Apr 30 2019 at 19:27, on Zulip):

Nice work getting the tests green :slight_smile:

detrumi (Apr 30 2019 at 19:28, on Zulip):

Any work left for this PR, or is it mainly review + finishing things up?

nikomatsakis (Apr 30 2019 at 19:28, on Zulip):

I was just wondering about that

nikomatsakis (Apr 30 2019 at 19:28, on Zulip):

I think I'm inclined to land it roughly as is and then try to do further cleanups in separate PRs

nikomatsakis (Apr 30 2019 at 19:28, on Zulip):

I wasn't happy with how complex the clauses.rs logic felt

nikomatsakis (Apr 30 2019 at 19:28, on Zulip):

That..might just be what it is :)

nikomatsakis (Apr 30 2019 at 19:28, on Zulip):

But I suspect we could at minimum refactor it a bit, and if not, we can at least document it better :)

nikomatsakis (Apr 30 2019 at 19:29, on Zulip):

Interestingly, this logic is actually "relevant" to the language spec -- or it will be -- because it will determine which specialization setups result in a cycle error and which do not

nikomatsakis (Apr 30 2019 at 19:29, on Zulip):

So it'd be nice to be able to document it more cleanly

nikomatsakis (Apr 30 2019 at 19:29, on Zulip):

Anyway, as I said, I suspect that's "future work"

detrumi (Apr 30 2019 at 19:30, on Zulip):

Sure, but the rustc code here felt a bit hacky too, in places

nikomatsakis (Apr 30 2019 at 19:30, on Zulip):

Oh, indeed

nikomatsakis (Apr 30 2019 at 19:30, on Zulip):

It's no hackier than rustc

detrumi (Apr 30 2019 at 19:30, on Zulip):

But definitely something to improve upon

nikomatsakis (Apr 30 2019 at 19:31, on Zulip):

Makes me wonder if we could express the program_clauses logic in some DSL and use that to derive clauses.rs too

nikomatsakis (Apr 30 2019 at 19:31, on Zulip):

but that's definitely future work :)

detrumi (Apr 30 2019 at 19:33, on Zulip):

A DSL? You mean some intermediate data structure that'd talk about what clauses to collect, without actually querying them from the database?

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

I don't know exactly what I mean :)

nikomatsakis (Apr 30 2019 at 20:10, on Zulip):

but in general the clauses.rs logic feels like it ought to be automatically derivable

nikomatsakis (Apr 30 2019 at 20:10, on Zulip):

although, as I said, it has lang implications, so it's not clear to me

nikomatsakis (Apr 30 2019 at 20:10, on Zulip):

anyway, yeah, let's land the PR

nikomatsakis (Apr 30 2019 at 20:10, on Zulip):

@scalexm -- do you happen to be around? do you want to look over https://github.com/rust-lang/chalk/pull/216 or are you happy if I just land it? :)

scalexm (Apr 30 2019 at 20:16, on Zulip):

@nikomatsakis could you wait tomorrow? I’ll give it a look in the morning

scalexm (Apr 30 2019 at 20:19, on Zulip):

Well anyway let’s land it, I’ll look at it in depth tomorrow and if anything stands out we can still make adjustments later, but I guess this won’t be necessary

nikomatsakis (Apr 30 2019 at 20:23, on Zulip):

no great rush

nikomatsakis (Apr 30 2019 at 20:23, on Zulip):

I think it can wait until tomorrow :)

nikomatsakis (May 03 2019 at 19:56, on Zulip):

@scalexm I made the change you suggested, can I merge https://github.com/rust-lang/chalk/pull/216 ?

scalexm (May 03 2019 at 19:56, on Zulip):

@nikomatsakis yes looks good

nikomatsakis (May 03 2019 at 20:01, on Zulip):

Merged, nice work @detrumi!

Aaron Hill (Jun 07 2019 at 18:55, on Zulip):

Hello - I'm interested in getting involved with this working group

Last update: Nov 12 2019 at 15:45UTC