Stream: wg-traits

Topic: visualizing the chalk-ir


nikomatsakis (Dec 17 2019 at 18:04, on Zulip):

Hey, so in the last meeting I was talking about trying to document the "intended plan" for chalk-ir. I started playing with a diagram that shows the various types of chalk-ir and their relation to the TF trait. It's not complete and it's also including a few changes beyond what the code currently does, but I'd be curious to see what folks think! That link should let you view and comment.

matklad (Dec 17 2019 at 21:07, on Zulip):

/me makes a mental note that rust-analyzer should learn to draw such diagrams one day...

nikomatsakis (Dec 17 2019 at 21:29, on Zulip):

heh I was wondering about that

nikomatsakis (Dec 17 2019 at 21:29, on Zulip):

did it make any sense to you, @matklad :)

nikomatsakis (Dec 17 2019 at 21:30, on Zulip):

woah, I can see your mouse cursor

nikomatsakis (Dec 17 2019 at 21:30, on Zulip):

I'm not sure I'd expect it to make sense all by itself

nikomatsakis (Dec 17 2019 at 21:31, on Zulip):

but it's meant to show the way chalk categorizes types (the yellow stuff) and the points where the representation can be customized (the green stuff)

nikomatsakis (Dec 17 2019 at 21:31, on Zulip):

I'd like to have each type be a link to the rustdoc (probably?) that would explain a bit the "rust syntax" it corresponds to

nikomatsakis (Dec 17 2019 at 21:31, on Zulip):

though i'm not sure if I can link

matklad (Dec 17 2019 at 21:32, on Zulip):

tbh, it doesn't make sense to me, but I haven't looked closely at the Tys after TF PR

matklad (Dec 17 2019 at 21:33, on Zulip):

I'd like to have each type be a link to the rustdoc (probably?)

Maybe just write all the interface bits in a single source file, such that imenu gives a nice overview?

nikomatsakis (Dec 17 2019 at 21:34, on Zulip):

(they are in a single file now)

matklad (Dec 17 2019 at 21:35, on Zulip):

One thing that especiially doesn't make sense to me is separate TF::TypeName and TF::DefId

nikomatsakis (Dec 17 2019 at 21:36, on Zulip):

a TypeName could be a def-id, but it could encode add'l info as well

nikomatsakis (Dec 17 2019 at 21:36, on Zulip):

e.g., u32

nikomatsakis (Dec 17 2019 at 21:37, on Zulip):

would be a TypeName

nikomatsakis (Dec 17 2019 at 21:37, on Zulip):

as would a built-in like Tuple

nikomatsakis (Dec 17 2019 at 21:37, on Zulip):

(at least in a rustc mapping)

nikomatsakis (Dec 17 2019 at 21:37, on Zulip):

there is of course no requirement that a given instantiation distinguish the two

matklad (Dec 17 2019 at 21:39, on Zulip):

Aha, that makes sense. On the diagram DefId is only used to encode associated_type_id (which I think is X in trait Foo { type X;}). If that's the case, I wonder if we can replace DefId with something simpler

nikomatsakis (Dec 17 2019 at 21:40, on Zulip):

simpler in what sense?

nikomatsakis (Dec 17 2019 at 21:40, on Zulip):

it is used for other things when we get to some of the other layers I've not included yet, I think

nikomatsakis (Dec 17 2019 at 21:40, on Zulip):

that said, I'm not sure that DefId is the right point to 'customize'

nikomatsakis (Dec 17 2019 at 21:41, on Zulip):

we have a lot of kinds of ids -- TraitId, StructId, etc

matklad (Dec 17 2019 at 21:41, on Zulip):

For assoc types, I think we can maybe use an relative index? Like, nth associated type

nikomatsakis (Dec 17 2019 at 21:41, on Zulip):

right now they are defined as "newtype'd" DefId, but it might be that they themselves should be associated types

nikomatsakis (Dec 17 2019 at 21:41, on Zulip):

For assoc types, I think we can maybe use an relative index? Like, nth associated type

ah. no thanks :)

nikomatsakis (Dec 17 2019 at 21:41, on Zulip):

I mean you could

nikomatsakis (Dec 17 2019 at 21:41, on Zulip):

but then you would still need a DefId for the trait

nikomatsakis (Dec 17 2019 at 21:41, on Zulip):

but also it's kind of a core simplification to GATs

nikomatsakis (Dec 17 2019 at 21:42, on Zulip):

that is, I think it's really best to think of the "items" in traits as things with their own IDs

nikomatsakis (Dec 17 2019 at 21:42, on Zulip):

I think that's what rust-analyzer is doing, no?

nikomatsakis (Dec 17 2019 at 21:42, on Zulip):

(from an incremental POV, this can also mean that when you reorder things, there is not necessarily an effect, but that's not the main motivation)

nikomatsakis (Dec 17 2019 at 21:43, on Zulip):

mainly, from chalk's POV, things get simpler if you can just think of associated types as being items with their own set of substitutions

nikomatsakis (Dec 17 2019 at 21:43, on Zulip):

well, I guess it doesn't matter that much, it's basically an opaque identifier, so we could make it TF::AssocTypeId for example

nikomatsakis (Dec 17 2019 at 21:43, on Zulip):

(and it could be mapped to whatever by the other side)

matklad (Dec 17 2019 at 21:43, on Zulip):

Yeah, at the momet assoc items have global ids

matklad (Dec 17 2019 at 21:44, on Zulip):

(in contrast to say, enum variants, which do have local ids)

nikomatsakis (Dec 17 2019 at 21:44, on Zulip):

yeah, though perhaps that should change too

nikomatsakis (Dec 17 2019 at 21:44, on Zulip):

i.e., if we ever make types for enum variants you might want them to have their own ids

nikomatsakis (Dec 17 2019 at 21:44, on Zulip):

but really I think that that the TF::DefId should prbably be replaced with TF::FooId

nikomatsakis (Dec 17 2019 at 21:44, on Zulip):

I remember that I had this in mind as a next step but I'd forgotten

nikomatsakis (Dec 17 2019 at 21:44, on Zulip):

this is partly why I started the chart

nikomatsakis (Dec 17 2019 at 21:45, on Zulip):

I want to iterate to what I think the "desired end state" should be a bit

matklad (Dec 17 2019 at 21:45, on Zulip):

TF::FooId rasies an interesting question of what is struct Foo(u32);

matklad (Dec 17 2019 at 21:45, on Zulip):

Like, it's simultaneously a struct and a function

nikomatsakis (Dec 17 2019 at 21:46, on Zulip):

yes, rustc assigns two distinct def-ids for this I think

nikomatsakis (Dec 17 2019 at 21:46, on Zulip):

we didn't always, @davidtwco did a bunch of work here, they'd remember best how it's setup probably :P

matklad (Dec 17 2019 at 21:46, on Zulip):

rust-analyzer uses one at the moment, but that maybe a bug in ra's design

nikomatsakis (Dec 17 2019 at 21:47, on Zulip):

anyway I'd have to check what the right set of ids are, I suspect it's something like

the question is how much we try to cast between them (very little, I think, except maybe at the more upper layers)

nikomatsakis (Dec 17 2019 at 21:47, on Zulip):

rust-analyzer uses one at the moment, but that maybe a bug in ra's design

I can't remember if we refactored it so that they share an id or not :)

nikomatsakis (Dec 17 2019 at 21:47, on Zulip):

I think not because it was useful for the non-exhaustive feature

Florian Diebold (Dec 17 2019 at 22:13, on Zulip):

rust-analyzer uses one at the moment, but that maybe a bug in ra's design

I think we actually used to distinguish it, but simplified it :sweat_smile:

nikomatsakis (Dec 20 2019 at 11:00, on Zulip):

I started a write-up of the chalk-ir setup here:

https://gist.github.com/nikomatsakis/a1e17c7d8f8647d7124cfdf9fec5b3bc

I plan to keep updating that gist with more details.

nikomatsakis (Dec 20 2019 at 11:01, on Zulip):

It's only got the highest level view right now, since I got distracted by other things this morning... :)

Jack Huey (Dec 20 2019 at 17:46, on Zulip):

@nikomatsakis this is super helpful imo

Jack Huey (Dec 20 2019 at 17:51, on Zulip):

What to name the TypeFamily? Since instances of it must be passed around, I've been considering TypeContext, as well, and to call those instances tcx: TypeContext, like in the compiler...?

So, as someone who hasn't really worked on the compiler: I _like_ TypeFamily, since it's a "family of types", but TypeContext sort of matches the Context from chalk-engine

Florian Diebold (Dec 20 2019 at 17:57, on Zulip):

to me, TypeFamily sounds more... type theoretic than it actually is, so I like TypeContext more

nikomatsakis (Dec 20 2019 at 18:31, on Zulip):

one wrinkle is that, in the compiler at least, we've been talking about renaming to "query context"

nikomatsakis (Dec 20 2019 at 18:31, on Zulip):

But I think the name TypeContext is pretty reasonable

matklad (Dec 20 2019 at 19:08, on Zulip):

My 2 buckets of paint:

nikomatsakis (Dec 20 2019 at 19:08, on Zulip):

yeah Repr is actually kind of interesting

nikomatsakis (Dec 20 2019 at 19:09, on Zulip):

note however

nikomatsakis (Dec 20 2019 at 19:09, on Zulip):

that I do expect to be passing around values (i.e., of type repr: &Repr)

nikomatsakis (Dec 20 2019 at 19:09, on Zulip):

I'm a bit unsure about just Context as there are a few other notions of Context

nikomatsakis (Dec 20 2019 at 19:09, on Zulip):

although I wonder if they can maybe be removed or at least better qualified

nikomatsakis (Dec 20 2019 at 19:16, on Zulip):

now I'm debating how to represent this document -- I can keep growing the gist, but maybe better to make an mdbook on wg-traits repo or something :) or just use the chalk book to draft it

Jack Huey (Dec 21 2019 at 00:29, on Zulip):

This seems like it definitely would be good for chalk book

nikomatsakis (Dec 21 2019 at 11:48, on Zulip):

I created https://github.com/rust-lang/chalk/pull/312

nikomatsakis (Dec 21 2019 at 11:48, on Zulip):

This contains an expanded version of the gist, but added to the chalk-book

Last update: Jun 07 2020 at 10:45UTC