Stream: t-compiler

Topic: eddyb's architectural sketch


eddyb (Apr 17 2019 at 20:11, on Zulip):

a few hours of inkscape later this is closer to what I was trying to express:
pasted image

eddyb (Apr 17 2019 at 20:11, on Zulip):

there must be an easier way to generate something like this though :P

Santiago Pastorino (Apr 17 2019 at 20:14, on Zulip):

@eddyb looks nice :)

eddyb (Apr 17 2019 at 20:15, on Zulip):

/me keeps copying messages from Discord:

eddyb (Apr 17 2019 at 20:15, on Zulip):

that's more or less the part that I don't see changing much, but everything outside Ty/Expr/Pat is finite structure and IMO should form the "definition spine" of a crate, off which Ty/Expr/Pat hang

Santiago Pastorino (Apr 17 2019 at 20:15, on Zulip):

@eddyb I wonder what about https://www.draw.io/ or https://www.figma.com/

eddyb (Apr 17 2019 at 20:15, on Zulip):

and this forms the basis of the "roadmap" I want to discuss at some point in the future

eddyb (Apr 17 2019 at 20:33, on Zulip):

added a few more details in: pasted image

eddyb (Apr 17 2019 at 20:46, on Zulip):

@Santiago Pastorino I'll take a look tomorrow, thanks!

Igor Matuszewski (Apr 17 2019 at 21:49, on Zulip):

@eddyb have a medal for this glorious piece of art :medal:

eddyb (Apr 18 2019 at 05:39, on Zulip):

I need to make it easier to edit though, because I need to have both "current state" and the future state

eddyb (Apr 18 2019 at 05:39, on Zulip):

and this is the wrong thread anyway, maybe I should split it off (EDIT: done)

eddyb (Apr 19 2019 at 09:25, on Zulip):

looking more at this... @nikomatsakis @oli @RalfJ would you think it would make more sense if instead of mir::Mir we'd have mir::Body?

eddyb (Apr 19 2019 at 09:26, on Zulip):

because then in HIR and THIR, Expr and Pat would be nested in one more thing, a Body, and then a THIR body would turn into a MIR body

eddyb (Apr 19 2019 at 09:26, on Zulip):

and maybe ty::Ty can become mir::Ty?

eddyb (Apr 19 2019 at 09:26, on Zulip):

/me ducks and runs

eddyb (Apr 19 2019 at 09:27, on Zulip):

(that is, the entirety of the {type,trait}-system would be considered as "part of MIR", and what we call "MIR" today would refer to the way fn/const bodies are represented in the "extended MIR universe")

RalfJ (Apr 19 2019 at 11:50, on Zulip):

Body vs Mir... I dont really care^^

RalfJ (Apr 19 2019 at 11:50, on Zulip):

your argument makes sense to me

matklad (Apr 19 2019 at 12:09, on Zulip):

+1 to representation where we have a flat-ish list of definitions (items), and, separately, some items have rich tree/graph based bodies.

matklad (Apr 19 2019 at 12:10, on Zulip):

We do have bodies in rust-analyzer :)

eddyb (Apr 21 2019 at 11:12, on Zulip):

@matklad convergence! I've been afraid of looking too much at rust-analyzer, but that makes sense

eddyb (Apr 21 2019 at 11:35, on Zulip):

haven't incorporated the MIR thing but tried an edit of @oli's graphviz: https://bit.ly/2IKL4E3

eddyb (Apr 21 2019 at 11:35, on Zulip):

(and yes, that would imply parsing doesn't output only AST)

matklad (Apr 21 2019 at 13:39, on Zulip):

I've been afraid of looking too much at rust-analyzer, but that makes sense

Why afraid? To have an unbiased overview of the design space? I'd love to discuss high-level architecture at some point. The thing I am struggling most with are spans: as far as I understand, the are pretty much ingrained into almost every rustc data structure, but in ra I doesn't have them: they make incremental hard, and they are lossy in a sense that it's hard to get from IR back to the syntax tree using spans (you can' but that feels not type-safe). That is, for IDE the arrows should be bidirectional, and, while spans can play some role in the inverse transform, I am not sure it's the right approach.

eddyb (Apr 21 2019 at 13:52, on Zulip):

IMO we need one or two indirection layers (or rather, two layers that are represented with one system):
- token ranges instead of character ranges
- split the inputs into "containers", like defs, or macro expansions (or make expansions defs but that feels weird)

nikomatsakis (Apr 22 2019 at 21:17, on Zulip):

@eddyb so I finally got some time to look at your sketch -- but I'm not sure if I understand the deeper ideas you are trying to convey

nikomatsakis (Apr 22 2019 at 21:18, on Zulip):

that said, I think that calling "MIR" the combination of types + MIR bodies etc is a really nice idea

nikomatsakis (Apr 22 2019 at 21:18, on Zulip):

although I'm not entirely convinced

nikomatsakis (Apr 22 2019 at 21:18, on Zulip):

(e.g., we might want to think about how chalk lowering can fit into this picture)

nikomatsakis (Apr 22 2019 at 21:24, on Zulip):

added this to my hackmd document with possible design meeting ideas

eddyb (Apr 23 2019 at 08:09, on Zulip):

I'd say Chalk operates entirely within MIR (which sits on Def)

eddyb (Apr 23 2019 at 08:13, on Zulip):

as for the sketch, I need to put some time into streamlining the process (with a generator from an easily-editable syntax), and adding all the details I want to, and have a version that accurately reflects today's state of things

eddyb (Apr 23 2019 at 08:22, on Zulip):

@nikomatsakis like, what you're seeing so far is the most basic skeleton of it

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

@nikomatsakis opened this issue, could go on your discussion ideas list https://github.com/rust-lang/rust/issues/60229

eddyb (Apr 26 2019 at 18:22, on Zulip):

@nikomatsakis @oli barely starting to convey something useful: today: https://bit.ly/2GBLppR -> future: https://bit.ly/2L4HYxp

eddyb (Apr 26 2019 at 18:24, on Zulip):

sadly, there's only so much a "cool diagram" (if at all) can show :(

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

@eddyb :heart_eyes: it's beautiful, whatever it means :P

eddyb (Apr 26 2019 at 19:34, on Zulip):

lol

Last update: Nov 20 2019 at 02:25UTC