Stream: t-compiler

Topic: why `hir::print` exists?


matklad (Aug 19 2019 at 20:49, on Zulip):

So, yeah, I am looking at hir::print and looks like what it does is pretty-printing of hir code as if it were an ast. Why do we need this? From my very limited understanding, hir is already an intermediate language, divorced from the surface syntax, so printing it in the original surface syntax doesn't make much sense to me. Like, would personally use s-expressions or just #[derive(Debug)] for seeing IRs

centril (Aug 19 2019 at 20:52, on Zulip):

It exists for debugging basically

centril (Aug 19 2019 at 20:52, on Zulip):

#[derive(Debug)]isn't helpful since it prints the IDs

centril (Aug 19 2019 at 20:54, on Zulip):

hir code as if it were an ast.

HIR is the real AST; syntax::ast is a CST

centril (Aug 19 2019 at 20:56, on Zulip):

I'd use something like RON or such; not a fan of lisp or s-expressions ;)

nikomatsakis (Aug 27 2019 at 19:16, on Zulip):

Yeah, I think it's a historical artifact for the most part. I think we should be moving towards more regular output -- derive(Debug) seems pretty ok to me.

centril (Oct 11 2019 at 15:14, on Zulip):

@nikomatsakis would you be OK with a PR that just rips out HIR pretty? it's a maintenance burden unfortunately

eddyb (Oct 11 2019 at 15:16, on Zulip):

maybe raise in design meeting or use FCP merge :P?

centril (Oct 11 2019 at 15:17, on Zulip):

@eddyb FCP merge seems least amount of work ^^

nikomatsakis (Oct 11 2019 at 15:42, on Zulip):

I think I'd be ok with it BUT I actually think we do need someone to champion a "reform" of how we do debug/display output

nikomatsakis (Oct 11 2019 at 15:43, on Zulip):

I really hate it that e.g. RUSTC_LOG=rustc_typeck tends to ICE the compiler these days

nikomatsakis (Oct 11 2019 at 15:43, on Zulip):

At this point I wish that {:?} were basically just straight-up debug output, except with minor additions (e.g., DefId should dump the def-path)

nikomatsakis (Oct 11 2019 at 15:43, on Zulip):

({} would stay basically what it is today)

nikomatsakis (Oct 11 2019 at 15:44, on Zulip):

I suspect that doing literally what I wrote would be a bit too much, but I think i'd want something very close to it

nikomatsakis (Oct 11 2019 at 15:44, on Zulip):

this does feel design meeting worthy

Zoxc (Oct 11 2019 at 15:54, on Zulip):

It is sometimes useful to print HIR and treat it as AST (and possibly compile it as AST) to show desugaring, etc.

nikomatsakis (Oct 11 2019 at 16:00, on Zulip):

Yes, this is true

centril (Oct 11 2019 at 16:00, on Zulip):

but HIR is also not entirely representable in AST

centril (Oct 11 2019 at 16:00, on Zulip):

which makes things weird

nikomatsakis (Oct 11 2019 at 16:01, on Zulip):

I certainly use it to figure out (e.g.) what the desugared form of format! is

nikomatsakis (Oct 11 2019 at 16:01, on Zulip):

Not sure if I could do that via AST dumping

nikomatsakis (Oct 11 2019 at 16:01, on Zulip):

That said, I'd also be happy with a "semi-readable" tree format of HIR for such things I think

centril (Oct 11 2019 at 16:01, on Zulip):

@nikomatsakis format! expands to syntax so you should be able to via -Z unpretty=expanded

nikomatsakis (Oct 11 2019 at 16:01, on Zulip):

yes, I was thinking the same

nikomatsakis (Oct 11 2019 at 16:01, on Zulip):

not sure what the right flag would be but probably there is one

centril (Oct 11 2019 at 16:02, on Zulip):
centril@centrilnas2:~/programming/rust/rust-gamma$ rustc foo.rs -Z unpretty=
error: argument to `unpretty` must be one of `normal`, `expanded`, `flowgraph[,unlabelled]=<nodeid>`, `identified`, `expanded,identified`, `everybody_loops`, `hir`, `hir,identified`, `hir,typed`, `hir-tree`, `mir` or `mir-cfg`; got
centril (Oct 11 2019 at 16:02, on Zulip):

@nikomatsakis I'm thinking we should unpretty HIR via a RON format or something... sorta Debug

nikomatsakis (Oct 11 2019 at 16:03, on Zulip):

try hir-tree

nikomatsakis (Oct 11 2019 at 16:03, on Zulip):

I think it is literally that

nikomatsakis (Oct 11 2019 at 16:03, on Zulip):

I added it because (a) the current format hides stuff (grr) and (b) some contributors wanted it to better understand how HIR works

nikomatsakis (Oct 11 2019 at 16:03, on Zulip):

this is another argument in favor of debug output (also for Ty)

nikomatsakis (Oct 11 2019 at 16:03, on Zulip):

it exposes the data structures much more clearly

nikomatsakis (Oct 11 2019 at 16:03, on Zulip):

my biggest frustration with the existing stuff is ICEs but also missing info

nikomatsakis (Oct 11 2019 at 16:04, on Zulip):

often it tries to make things pretty but if things are not setup right that just kind of hides what I need to know

nikomatsakis (Oct 11 2019 at 16:04, on Zulip):

otoh sometimes it's very nice that I don't have to decrypt :)

centril (Oct 11 2019 at 16:05, on Zulip):

@nikomatsakis yeah; and we need to spend effort into updating HIR pretty when we change HIR also... and we can forget to include things

Last update: Nov 16 2019 at 01:35UTC