Stream: wg-traits

Topic: reintegrating chalk into rustc


Jack Huey (Feb 08 2020 at 02:44, on Zulip):

So I did a thing and the rustc builds with the latest Chalk version

Jack Huey (Feb 08 2020 at 02:44, on Zulip):

Now, there are definitely some todo!()s

Jack Huey (Feb 08 2020 at 02:45, on Zulip):

And keeps the same scheme as before - where everything is built around chalk-engine

Jack Huey (Feb 08 2020 at 02:45, on Zulip):

But it at least is a starting point (for me at least)

Jack Huey (Feb 08 2020 at 02:46, on Zulip):

Now, two questions:

Jack Huey (Feb 08 2020 at 02:46, on Zulip):

Actually maybe three

Jack Huey (Feb 08 2020 at 02:47, on Zulip):

1) Maybe we should regularly publish chalk versions to crates.io, even if they're still 0.x.x for now

Jack Huey (Feb 08 2020 at 02:47, on Zulip):

2) Should I push this to a branch so people can check it out?

Jack Huey (Feb 08 2020 at 02:48, on Zulip):

3) Is it more worth it to completely rip out the existing integration and start fresh

nikomatsakis (Feb 08 2020 at 11:21, on Zulip):

Interesting. I was debating about this.

nikomatsakis (Feb 08 2020 at 11:22, on Zulip):

It seems like some folks are blocked on the current chalk integration, so I think it makes sense to do something to change that ASAP

nikomatsakis (Feb 08 2020 at 11:22, on Zulip):

I do think we should probably get in the habit of publishing regular versions to crates.io

nikomatsakis (Feb 08 2020 at 11:24, on Zulip):

I am debating about whether it makes sense to try and remove the existing integration or upgrade it -- I guess I don't have a strong feeling. The benefits I see of upgrading are

The benefits I see of removing are

Jack Huey (Feb 08 2020 at 22:17, on Zulip):

So, the idea I was going for is: Can I spend only a bit of time and get rustc to build with the latest version of Chalk, so we can start to unblock issues like https://github.com/rust-lang/rust/pull/68807. Under the assumption that we don't particularly care if it works.

Jack Huey (Feb 08 2020 at 22:18, on Zulip):

And yes, it's completely possible and only about an hour of work

Jack Huey (Feb 08 2020 at 22:19, on Zulip):

But, I also sort of think that a lot of the existing code will be replaced when we move to use chalk-solve

Jack Huey (Feb 08 2020 at 23:27, on Zulip):

Shoot, I know this was talked about at some point (I think), but what was the reasoning for making all the functions of TypeFamily (particularly here the intern* functions) take no parameter that could store state

Jack Huey (Feb 08 2020 at 23:29, on Zulip):

So, like in ChakIr and rust-analyzer intern_goal just returns Arc::new(goal). But in rustc, the goals are actually interned on TyCtxt

Jack Huey (Feb 08 2020 at 23:42, on Zulip):

Ok in hindsight https://github.com/rust-lang/chalk/commit/9f5d084d3cd39feba2a6264d879ffc4e1c09d9e8#diff-f8d532fdb5ed1dd1137e521e1fb3f704 was a bad commit

Jack Huey (Feb 09 2020 at 00:03, on Zulip):

Oh hey, all the -Z chalk tests pass

Jack Huey (Feb 09 2020 at 00:06, on Zulip):

that can't be right....too many todo!()s

Jack Huey (Feb 09 2020 at 00:59, on Zulip):

update: it wasn't right

Jack Huey (Feb 09 2020 at 01:00, on Zulip):

So, next roadblock

Jack Huey (Feb 09 2020 at 01:00, on Zulip):

instantiate_ucanonical_goal and instantiate_ex_clause

Jack Huey (Feb 09 2020 at 01:01, on Zulip):

And I knew this one was coming

Jack Huey (Feb 09 2020 at 01:02, on Zulip):

But, the essentially impl Fn arg was added to these for when Chalk was originally integrated with rustc

Jack Huey (Feb 09 2020 at 01:02, on Zulip):

But in the name of simplicity, these have been reverted back to just returning the instantiated forms

Jack Huey (Feb 09 2020 at 01:02, on Zulip):

(which works fine in chalk-solve)

Jack Huey (Feb 09 2020 at 01:04, on Zulip):

but in rustc the InferenceTable includes a reference to InferCtxt, which is passed as an arg to the function provided to enter_with_canonical

Jack Huey (Feb 09 2020 at 01:06, on Zulip):

now, instantiate_ucanonical_goal doesn't seem too bad, I don't think, since the two times we use it, the return values are "short-lived"

Jack Huey (Feb 09 2020 at 01:06, on Zulip):

now, instantiate_ex_clause is a bit more difficult

Jack Huey (Feb 09 2020 at 01:06, on Zulip):

since that makes a Strand, which we store on the Stack

Jack Huey (Feb 09 2020 at 01:12, on Zulip):

now, looking through chalk-engine a bit, I think we could actually get away with instantiating the ExClause further down, instead of when we pop the CanonicalStrand

Jack Huey (Feb 09 2020 at 01:12, on Zulip):

Though, this does mean more calls to instantiate it

Jack Huey (Feb 09 2020 at 01:14, on Zulip):

Maybe I should step back and clarify why requiring that instantiate_ex_clause take a function with a scoped reference is a bad thing right now:

Jack Huey (Feb 09 2020 at 01:14, on Zulip):

it means that we have to start thinking recursively again

Jack Huey (Feb 09 2020 at 01:17, on Zulip):

Also, looking back at https://github.com/rust-lang/chalk/pull/277

Jack Huey (Feb 09 2020 at 01:18, on Zulip):

specifically this Clone bound: https://github.com/rust-lang/chalk/pull/277/files#diff-f8d532fdb5ed1dd1137e521e1fb3f704R80

Jack Huey (Feb 09 2020 at 01:18, on Zulip):

I think that scheme wouldn't work for rustc

Jack Huey (Feb 09 2020 at 01:22, on Zulip):

Now, the other question is: do we really have to think about this, or will switching to chalk-solve fix this automatically

Jack Huey (Feb 09 2020 at 01:24, on Zulip):

I have a feeling we're gonna run into this somewhere

Jack Huey (Feb 09 2020 at 01:24, on Zulip):

So, like in ChakIr and rust-analyzer intern_goal just returns Arc::new(goal). But in rustc, the goals are actually interned on TyCtxt

maybe it's here

nikomatsakis (Feb 10 2020 at 19:30, on Zulip):

Shoot, I know this was talked about at some point (I think), but what was the reasoning for making all the functions of TypeFamily (particularly here the intern* functions) take no parameter that could store state

I think we want to add such a parameter

nikomatsakis (Feb 10 2020 at 19:30, on Zulip):

the reasoning was "incremental steps", but that's one of the big refactorings yet to come I think

Jane Lusby (Feb 11 2020 at 03:18, on Zulip):

Question, would throwing more people at chalk integration help it get into the compiler faster? I'd be interested in dedicating time to help out if the issue is just lack of people hours and you can just throw blockers at me to grind away at, but if the issue is just the complexity of the issue I would rather not distract from the work.

detrumi (Feb 11 2020 at 06:06, on Zulip):

We definitely could use some help! We're in the process of organizing things better so we can split up tasks, so I expect you can help out

matprec (Feb 11 2020 at 10:38, on Zulip):

I'm interested as well but it always seemed that people are busy enough to get their own tasks done :D

matprec (Feb 11 2020 at 10:39, on Zulip):

Feel free to ping me if there is something easy to tackle :)

Jack Huey (Feb 11 2020 at 14:47, on Zulip):

Yes @Jane Lusby @matprec, there are always things to do :) As @detrumi said, we're in process of setting up a sprint for the next 6 weeks, so be on the lookout for a blog post (or hang around the channel)

Jane Lusby (Feb 11 2020 at 15:07, on Zulip):

Okay well write my name down and assign me issues, I have Sunjay who can mentor me on getting started with chalk so I think I'll be able to get up and running quickly

Jane Lusby (Feb 11 2020 at 15:07, on Zulip):

Definitely extremely interested in chalk integration

Sunjay Varma (Feb 11 2020 at 15:16, on Zulip):

(I should note that I'm happy to help Jane get started if anyone needs me to, but I'm not really involved very much right now because of a lot of things going on in my personal life. Hoping to come back in a few months in a way where I can be much more consistent in my contributions!)

Jack Huey (Feb 14 2020 at 14:50, on Zulip):

@nikki

Jack Huey (Feb 14 2020 at 14:50, on Zulip):

Whoops

Jack Huey (Feb 14 2020 at 14:50, on Zulip):

Was doing more work on integrating chalk into rustc last night

Jack Huey (Feb 14 2020 at 14:51, on Zulip):

Specifically, using chalk-solve and chalk-ir

Jack Huey (Feb 14 2020 at 14:51, on Zulip):

And came across this problem:

Jack Huey (Feb 14 2020 at 14:52, on Zulip):

So, in TypeFamily, the _data functions return back a reference

Jack Huey (Feb 14 2020 at 14:52, on Zulip):

Which, makes sense if the argument is a reference

Jack Huey (Feb 14 2020 at 14:53, on Zulip):

But, when we have to create a new TyData instance, it doesn't work

Jack Huey (Feb 14 2020 at 14:53, on Zulip):

(rust-analyzer also has this problem)

Jack Huey (Feb 14 2020 at 14:55, on Zulip):

So I was thinking, rather than returning a reference, we could have the _data functions take a function that is called with the reference to the TyData

Jack Huey (Feb 14 2020 at 14:55, on Zulip):

So, for the default TypeFamily, it just passes the argument

Jack Huey (Feb 14 2020 at 14:56, on Zulip):

But for rustc or rust-analyzer, where we have to create a TyData, we don't have to store it anywhere

Jack Huey (Feb 14 2020 at 14:57, on Zulip):

Just wanted to know what you thought

Jack Huey (Feb 14 2020 at 15:05, on Zulip):

Either that, or make _data functions return a non-reference TyData

Jack Huey (Feb 14 2020 at 15:05, on Zulip):

(I guess this same problem applies for other types other than Ty/TyData)

Jack Huey (Feb 14 2020 at 15:42, on Zulip):

Actually maybe @Florian Diebold might want to chime in here too (or has an opinion), since they do the rust-analyzer related work, I think

Florian Diebold (Feb 14 2020 at 15:54, on Zulip):

we would also have this problem in RA, yeah, at least until we completely switch to Chalk's type representation. I guess the idea is that the type family is really just interning types, not synthesizing them on the fly.

have the _data functions take a function that is called with the reference to the TyData

that seems a bit weird as an API, but I guess it would work. Another alternative might just be returning a Cow...

Florian Diebold (Feb 14 2020 at 15:54, on Zulip):

on the other hand, if rustc is fine synthesizing TyDatas performance-wise, why not just return an owned TyData :thinking:

Jack Huey (Feb 14 2020 at 15:56, on Zulip):

Florian Diebold said:

that seems a bit weird as an API, but I guess it would work. Another alternative might just be returning a Cow...

Jack Huey (Feb 14 2020 at 15:56, on Zulip):

whoops

Jack Huey (Feb 14 2020 at 15:57, on Zulip):

not entirely a weird api, it's essentially the same as like tls apis

Jack Huey (Feb 14 2020 at 16:00, on Zulip):

maybe I'm just misunderstanding the goal a bit. The current TypeFamily seems to be mostly not super useful unless your InternedTy is TyData (as is the default TypeFamily)

Jack Huey (Feb 14 2020 at 16:01, on Zulip):

or you store the TyData in your InternedType

Jack Huey (Feb 14 2020 at 16:02, on Zulip):

I thought it was supposed to act as sort of a "bridge"

nikomatsakis (Feb 14 2020 at 18:59, on Zulip):

Jack Huey said:

So I was thinking, rather than returning a reference, we could have the _data functions take a function that is called with the reference to the TyData

nope :)

nikomatsakis (Feb 14 2020 at 19:00, on Zulip):

or at least

nikomatsakis (Feb 14 2020 at 19:00, on Zulip):

it was designed the way it is

nikomatsakis (Feb 14 2020 at 19:00, on Zulip):

intentionally

nikomatsakis (Feb 14 2020 at 19:00, on Zulip):

I would prefer that we return references

nikomatsakis (Feb 14 2020 at 19:00, on Zulip):

(sorry, I hate the way I reply nope without thinking how jerky that sounds ;) please accept my apology!)

nikomatsakis (Feb 14 2020 at 19:00, on Zulip):

let me back up and enumerate:

nikomatsakis (Feb 14 2020 at 19:00, on Zulip):

what I had hope to do in the case of rustc was this

nikomatsakis (Feb 14 2020 at 19:01, on Zulip):
nikomatsakis (Feb 14 2020 at 19:01, on Zulip):
nikomatsakis (Feb 14 2020 at 19:01, on Zulip):
nikomatsakis (Feb 14 2020 at 19:02, on Zulip):

in the case of rust analyzer, ideally there would be no map at all

nikomatsakis (Feb 14 2020 at 19:02, on Zulip):

they would just be using chalk's types

nikomatsakis (Feb 14 2020 at 19:02, on Zulip):

and if that's a problem, then we should see why and adjust chalk's types

nikomatsakis (Feb 14 2020 at 19:02, on Zulip):

so that it can work

nikomatsakis (Feb 14 2020 at 19:02, on Zulip):

longer term, I would think rustc would also just be using chalk's types

nikomatsakis (Feb 14 2020 at 19:02, on Zulip):

I would really prefer not to use Cow or the TLS-style APIs,

nikomatsakis (Feb 14 2020 at 19:03, on Zulip):

TLS beacuse it'll be annoying as all get out in practice

nikomatsakis (Feb 14 2020 at 19:03, on Zulip):

Cow because you really don't want to be allocating this data every time anyway I don't think and because it's also kind of complex :)

nikomatsakis (Feb 14 2020 at 19:03, on Zulip):

Anyway, what do you think about those directions? I could imagine there's a flaw

nikomatsakis (Feb 14 2020 at 19:04, on Zulip):

nikomatsakis said:

in the case of rust analyzer, ideally there would be no map at all

but I guess @Florian Diebold might be able to tell us how feasible this is :)

Florian Diebold (Feb 14 2020 at 19:13, on Zulip):

so far it's not been possible because the TypeFamily can't carry any context, I think once that is changed it should be doable. I'm a bit wary about the inference code becoming more verbose, but we'll see

nikomatsakis (Feb 14 2020 at 19:14, on Zulip):

Interesting!

nikomatsakis (Feb 14 2020 at 19:15, on Zulip):

One of the things I wanted to mentor for this sprint is adding context to TypeFamily

nikomatsakis (Feb 14 2020 at 19:15, on Zulip):

let's prioritize that

Jack Huey (Feb 14 2020 at 19:17, on Zulip):

Interesting

Jack Huey (Feb 14 2020 at 19:19, on Zulip):

Thanks for the feedback :)

Jane Lusby (Feb 14 2020 at 19:19, on Zulip):

nikomatsakis said:

One of the things I wanted to mentor for this sprint is adding context to TypeFamily

I'd be interested in working on this if you're looking for a mentee

nikomatsakis (Feb 14 2020 at 19:22, on Zulip):

Florian Diebold said:

so far it's not been possible because the TypeFamily can't carry any context, I think once that is changed it should be doable. I'm a bit wary about the inference code becoming more verbose, but we'll see

this would also be useful to know

nikomatsakis (Feb 14 2020 at 19:22, on Zulip):

I do think eventually we should have everyone using a library like chalk-ty to represent their types, so if we can figure out what's the most ergonomic/correct set of variants, would be good

nikomatsakis (Feb 14 2020 at 19:23, on Zulip):

@Florian Diebold are you using the salsa interning mechanism, too?

Florian Diebold (Feb 14 2020 at 19:27, on Zulip):

yes

nikomatsakis (Feb 14 2020 at 19:28, on Zulip):

OK, good. Or I mean "bad", in the sense that it means you also need &self during lookup

nikomatsakis (Feb 14 2020 at 19:28, on Zulip):

but I think that's the right design anyway

Florian Diebold (Feb 14 2020 at 19:29, on Zulip):

one thing that might be nice would be having TypeName be an associated type of the TypeFamily, so we can keep it as a richer enum (so we don't need to intern things all the time during inference)

nikomatsakis (Feb 14 2020 at 19:32, on Zulip):

Yeah, I was debating about whether TypeName should be an associated type or not

Jack Huey (Feb 14 2020 at 20:40, on Zulip):

There was another thing I found that I should bring up

Jack Huey (Feb 14 2020 at 20:40, on Zulip):

why are all the Interned types required to be Ord

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

could be no reason :)

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

or could be that use BTreeMap in some places for determinism

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

we could probably switch to rustc-hash

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

if it's the latter

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

that didn't used to exist at the time

Jack Huey (Feb 14 2020 at 20:41, on Zulip):

I removed Ord on all of them (because rustc)

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

seems ok, if it built

Jack Huey (Feb 14 2020 at 20:41, on Zulip):

and there was only one BTreeSet use

Jack Huey (Feb 14 2020 at 20:41, on Zulip):

for program_clauses

Jack Huey (Feb 14 2020 at 20:41, on Zulip):

somewhere related to that

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

yeah ok

nikomatsakis (Feb 14 2020 at 20:42, on Zulip):

I think we could switch to rustc-hash

nikomatsakis (Feb 14 2020 at 20:42, on Zulip):

I don't think we care what ordering we have, just that it is consistent run to run for the same inputs

Jack Huey (Feb 14 2020 at 20:42, on Zulip):

probably

nikomatsakis (Feb 14 2020 at 20:42, on Zulip):

anyway rustc-hash would be faster!

Jack Huey (Feb 14 2020 at 20:43, on Zulip):

I also had to make a bunch of misc. changes like removing extern crates, HashMap to FxHashMap, Formatter to Formatter<'_>

Jack Huey (Feb 14 2020 at 20:43, on Zulip):

I'll probably make a PR with just those changes at some point

Jack Huey (Feb 14 2020 at 20:44, on Zulip):

Also, if the determinism is important, it's not currently checked by any tests

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

it's more that tests didn't work

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

Jack Huey said:

I also had to make a bunch of misc. changes like removing extern crates, HashMap to FxHashMap, Formatter to Formatter<'_>

eh? are we not on rust 2018?

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

anyway that PR seems good

Jack Huey (Feb 14 2020 at 20:45, on Zulip):

edition = "2018"

Jack Huey (Feb 14 2020 at 20:45, on Zulip):

but still :shrug:‍♂️

Jack Huey (Feb 15 2020 at 22:32, on Zulip):

So I realized that not having a interner value passed an argument is not a blocker (necessarily), because we can "get it to work" by using tls

Jack Huey (Feb 15 2020 at 22:34, on Zulip):

that being said, I've actually got the skeleton of chalk-solve/chalk-ir set up

Jack Huey (Feb 15 2020 at 22:34, on Zulip):

everything in RustIrDatabase is unimplemented!()

Jack Huey (Feb 15 2020 at 22:34, on Zulip):

and everything in Interner essentially just matched the default

Jack Huey (Feb 15 2020 at 22:34, on Zulip):

but getting there

Jack Huey (Feb 16 2020 at 02:02, on Zulip):

Jack Huey said:

So I realized that not having a interner value passed an argument is not a blocker (necessarily), because we can "get it to work" by using tls

:face_palm:‍♂️nevermind this

Jack Huey (Feb 19 2020 at 00:00, on Zulip):

Ok so I have integrated chalk-solve/chalk-ir into rustc just enough to be able to lower the most basic rustc goal and some traits/structs/impls

Jack Huey (Feb 19 2020 at 00:00, on Zulip):

but it's not right

Jack Huey (Feb 19 2020 at 00:00, on Zulip):

and I'm doing something very unsafe in order to be able to actually intern types

Jack Huey (Feb 19 2020 at 00:01, on Zulip):

(using tls TyCtxt and transmuting lifetime)

Jack Huey (Feb 19 2020 at 00:01, on Zulip):

so it's not actually correct

Jack Huey (Feb 19 2020 at 00:02, on Zulip):

but theoretically, that should be a local fix once @Jane Lusby's changes get merged

Jack Huey (Feb 19 2020 at 00:02, on Zulip):

in the meantime, I gotta figure out why the simple query I am doing is failing

Jane Lusby (Feb 19 2020 at 00:02, on Zulip):

soon :tm:

Jack Huey (Feb 19 2020 at 00:03, on Zulip):

somewhere, a TraitRef is getting created with an empty substitution

Jack Huey (Feb 19 2020 at 00:03, on Zulip):

but I don't think it's because of how I'm lowering to TraitRefs directly. I think it has to do with the Binders

Jack Huey (Feb 23 2020 at 21:16, on Zulip):

https://github.com/rust-lang/chalk/pull/332 and https://github.com/rust-lang/rust/pull/69406

nikomatsakis (Feb 24 2020 at 18:04, on Zulip):

@Jack Huey nice, will take a look, I have a question --

nikomatsakis (Feb 24 2020 at 18:04, on Zulip):

there was this PR about removing the existing integration

nikomatsakis (Feb 24 2020 at 18:05, on Zulip):

I have to look it over but I was thinking of merging it, just to undo the old dependency

nikomatsakis (Feb 24 2020 at 18:05, on Zulip):

do you think that would make this PR harder?

nikomatsakis (Feb 24 2020 at 18:05, on Zulip):

seems like "probably not"

Jack Huey (Feb 24 2020 at 18:20, on Zulip):

So, in some ways, yes

Jack Huey (Feb 24 2020 at 18:21, on Zulip):

because that PR also removes all the infrastructure for -Z chalk

Jack Huey (Feb 24 2020 at 18:22, on Zulip):

and there are some places like here https://github.com/rust-lang/rust/pull/69247/files#diff-f485b4e6b0c24b409813516a33e7083aL360 that are doing something special for Chalk (unsure exactly why)

Jack Huey (Feb 24 2020 at 18:23, on Zulip):

that's not to say I can't revert that PR as my first commit in my PR

Jack Huey (Feb 24 2020 at 18:23, on Zulip):

(since a good chunk of that code does get removed/changed anyways)

nikomatsakis (Feb 24 2020 at 19:42, on Zulip):

OK, that PR perhaps goes a bit too far then

Jack Huey (Feb 24 2020 at 22:38, on Zulip):

@nikomatsakis you around?

Jack Huey (Feb 24 2020 at 22:38, on Zulip):

question about rustc I think

Jack Huey (Feb 24 2020 at 22:39, on Zulip):

related to https://github.com/rust-lang/chalk/issues/261

Jack Huey (Feb 24 2020 at 22:40, on Zulip):

do you know what the best way to generate these clauses are?

nikomatsakis (Feb 24 2020 at 22:49, on Zulip):

well

nikomatsakis (Feb 24 2020 at 22:49, on Zulip):

Sized is maybe the trickiest to start with

nikomatsakis (Feb 24 2020 at 22:49, on Zulip):

I realize now

nikomatsakis (Feb 24 2020 at 22:49, on Zulip):

or, maybe not

nikomatsakis (Feb 24 2020 at 22:49, on Zulip):

there is some specialized code in rustc to handle Sized

nikomatsakis (Feb 24 2020 at 22:49, on Zulip):

but I think it's primarily done that way for efficiency

nikomatsakis (Feb 24 2020 at 22:50, on Zulip):

/me thinks

nikomatsakis (Feb 24 2020 at 22:50, on Zulip):

the short version is that there will be some custom code in chalk-solve I think

nikomatsakis (Feb 24 2020 at 22:50, on Zulip):

that looks at the "Self type" and generates some clauses

nikomatsakis (Feb 24 2020 at 22:51, on Zulip):

in the case of SomeStruct: Sized (i.e., where self-type is a struct type) we would want to check that the fields are Sized -- in fact, the actual rules are that only the final field can be unsized I think, so that's really the only type you have to check

nikomatsakis (Feb 24 2020 at 22:51, on Zulip):

it might be easier to start with some of the other well-known traits, e.g. Clone

nikomatsakis (Feb 24 2020 at 22:51, on Zulip):

Clone is interesting in that it has a mix of user-given impls and -- for some types, like closures -- we auto-generate impls

nikomatsakis (Feb 24 2020 at 22:51, on Zulip):

the current chalk-ir doesn't recognize those distinctions I guess

Jack Huey (Feb 24 2020 at 22:52, on Zulip):

So, for reference, I'm trying to get the most basic possible program to compile successfully

nikomatsakis (Feb 24 2020 at 22:52, on Zulip):

we should make a list of all the built-in traits that are required and start to list them out with some notes on what their impls are

Jack Huey (Feb 24 2020 at 22:52, on Zulip):
trait Foo {}

struct Bar {}

impl Foo for Bar {}

fn main() -> () {
}
nikomatsakis (Feb 24 2020 at 22:52, on Zulip):

ah, ok, and you're hitting the need for Sized specifically I guess

Jack Huey (Feb 24 2020 at 22:52, on Zulip):

exactly

nikomatsakis (Feb 24 2020 at 22:52, on Zulip):

well basically the rule would be that, for a struct type, all the fields must be sized

Jack Huey (Feb 24 2020 at 22:52, on Zulip):

BUT, unimplemented!()s get called

nikomatsakis (Feb 24 2020 at 22:52, on Zulip):

that's more than you need but it's ok

nikomatsakis (Feb 24 2020 at 22:53, on Zulip):

good starting point

Jack Huey (Feb 24 2020 at 22:53, on Zulip):

I mean, there is https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyS.html#method.is_sized

Jack Huey (Feb 24 2020 at 22:53, on Zulip):

I don't know if I can use that

Jack Huey (Feb 24 2020 at 22:53, on Zulip):

The problem right now, is I assume I would have to return that impl in impls_for_trait

Jack Huey (Feb 24 2020 at 22:54, on Zulip):

but, then I would have to return all impls for Sized

Jack Huey (Feb 24 2020 at 22:55, on Zulip):

I guess Sized is an auto trait?

Jack Huey (Feb 24 2020 at 23:19, on Zulip):

Well, not exactly

Jack Huey (Feb 24 2020 at 23:20, on Zulip):

but that scheme seems to work here

Jack Huey (Feb 24 2020 at 23:20, on Zulip):

since, chalk-solve calls impl_provided_for for auto traits

Jack Huey (Feb 24 2020 at 23:27, on Zulip):

Sized is special

Jack Huey (Feb 24 2020 at 23:31, on Zulip):

This makes me think. Maybe chalk-ir needs a bit of refining in regards to auto traits. They really represent a couple things right now: coinductive (which is a separate flag too), non_enumerable (also a separate flag too), and this "late implementations" (similar to the idea of non-enumerability, but we can generate a single clause given a struct via impl_provided_for)

Jack Huey (Feb 24 2020 at 23:32, on Zulip):

So, maybe "auto trait" in chalk-ir should also should only mean that bit (renamed maybe too). And both actual auto traits and Sized would have that flag

Jack Huey (Feb 24 2020 at 23:33, on Zulip):

I actually don't think Clone is that special tbh

Jack Huey (Feb 25 2020 at 00:01, on Zulip):

ok so I (with tons of hacks) got all of the goals from the basic test to return a Unique Solution.

Jack Huey (Feb 25 2020 at 00:02, on Zulip):

And I expected that to cause the test to pass

Jack Huey (Feb 25 2020 at 00:02, on Zulip):

But it still fails

Jack Huey (Feb 25 2020 at 00:02, on Zulip):

But I don't get any info why

Jack Huey (Feb 25 2020 at 00:02, on Zulip):

:shrug:‍♂️

Jack Huey (Feb 25 2020 at 00:04, on Zulip):

So, I'm probably lowering something as a struct or something where it should be variable

Jack Huey (Feb 25 2020 at 00:07, on Zulip):

Jack Huey said:

but we can generate a single clause given a struct via impl_provided_for)

Also, I realized this isn't correct. We generate the impl if this is false

Jack Huey (Feb 25 2020 at 00:11, on Zulip):

oh haha

Jack Huey (Feb 25 2020 at 00:11, on Zulip):

I had to --bless the test :sweat_smile:

Jack Huey (Feb 25 2020 at 00:12, on Zulip):

That means....first passing test with Chalk reintegration

Jack Huey (Feb 25 2020 at 00:12, on Zulip):

(don't pay attention to the terrible hacks done to get this specific test to pass)

Jack Huey (Feb 25 2020 at 00:14, on Zulip):

image.png

Jack Huey (Feb 25 2020 at 00:14, on Zulip):

wait...

Jack Huey (Feb 25 2020 at 00:15, on Zulip):

image.png it was because it had already ran/passed

Last update: Feb 25 2020 at 03:30UTC