Stream: t-compiler/wg-nll

Topic: pretty printing thoughts


davidtwco (Oct 09 2018 at 13:05, on Zulip):

I would prefer if the shorthand way that things like Place print - ie. Place::Local(Local(0)) being _0 would be on Display and we use the derive'd Debug for things. It would be super helpful in being able to identify the specific case I'm seeing if I could just print it out as the types. Particularly when first starting to contribute and you aren't familiar with how to work backwards from *(*(_2.3).9) or something like that. There are other types where it's much more a pain too.

davidtwco (Oct 09 2018 at 13:06, on Zulip):

(in reply to some comments on pretty printing in #54499 Invalid "variable does not need to be mutable" topic)

nikomatsakis (Oct 09 2018 at 13:09, on Zulip):

I am torn

nikomatsakis (Oct 09 2018 at 13:09, on Zulip):

the derive(Debug) output is often ridiculously painful

nikomatsakis (Oct 09 2018 at 13:09, on Zulip):

but I agree that the shorthands are often unnecessarily cryptic

nikomatsakis (Oct 09 2018 at 13:09, on Zulip):

on balance I think I would prefer that we use Debug a lot more often

nikomatsakis (Oct 09 2018 at 13:09, on Zulip):

and I want :? to basically never lose data

nikomatsakis (Oct 09 2018 at 13:09, on Zulip):

which is not at all the case today

nikomatsakis (Oct 09 2018 at 13:10, on Zulip):

I don't like the idea of using {}

nikomatsakis (Oct 09 2018 at 13:10, on Zulip):

In fact, I think I don't even like that we implement Debug for things

nikomatsakis (Oct 09 2018 at 13:10, on Zulip):

mostly because there is often a need to thread down context

nikomatsakis (Oct 09 2018 at 13:10, on Zulip):

to get a good printout

nikomatsakis (Oct 09 2018 at 13:11, on Zulip):

I don't like the idea of using {}

specifically, I think that should be reserved for "end-user" output, as is its intention

nikomatsakis (Oct 09 2018 at 13:11, on Zulip):

I think impl'ing Debug is prob — on balance — the right thing, but it'd be nice if there was a foo.debug_with(context) thing we could use

nikomatsakis (Oct 09 2018 at 13:11, on Zulip):

such that you could (e.g.) do place.debug_with(mir) and get better output

davidtwco (Oct 09 2018 at 13:11, on Zulip):

Yeah. It'd be nice to find some balance where we print something concise but that's also easy to work out what it represents - particularly for new contributors. I know that I spent a lot of time when starting out just iterating on debug statements to slowly but surely work out what the type I had actually was.

nikomatsakis (Oct 09 2018 at 13:12, on Zulip):

similarly maybe we could have something like debug!("{}", foo.pretty_print())

nikomatsakis (Oct 09 2018 at 13:12, on Zulip):

vs debug!("{:?}", foo), which uses derive(debug) output

nikomatsakis (Oct 09 2018 at 13:12, on Zulip):

foo.pretty_print(cx)

nikomatsakis (Oct 09 2018 at 13:12, on Zulip):

hmm, maybe we should just start adding that

nikomatsakis (Oct 09 2018 at 13:12, on Zulip):

my idea would be to have a PrettyPrint<Context> trait

nikomatsakis (Oct 09 2018 at 13:12, on Zulip):

and lean on specialization

pnkfelix (Oct 09 2018 at 13:12, on Zulip):

I don't suppose I could convince you to name the method pp()

nikomatsakis (Oct 09 2018 at 13:13, on Zulip):

I've become pretty anti-contraction

pnkfelix (Oct 09 2018 at 13:13, on Zulip):

just to keep us from having to break lines all over the place for tidy's sake

nikomatsakis (Oct 09 2018 at 13:13, on Zulip):

but I could be convinced in this case to make an exception

davidtwco (Oct 09 2018 at 13:13, on Zulip):

That's what I tried to implement before when one of my PRs intersected with the ppaux code.

nikomatsakis (Oct 09 2018 at 13:13, on Zulip):

in part because typing pretty_print is pretty tedious

pnkfelix (Oct 09 2018 at 13:14, on Zulip):

I'm still not sure why we couldn't leverage {:#?} in some way

pnkfelix (Oct 09 2018 at 13:14, on Zulip):

instead of adding new machinery...

davidtwco (Oct 09 2018 at 13:15, on Zulip):

Contractions for really common things - like tcx - are great, but unnecessary contractions were another barrier that I remember when first starting out. By no means insurmountable, but even now if I'm diving into some code I've not touched before, it's super valuable if things have sensible names.

pnkfelix (Oct 09 2018 at 13:15, on Zulip):

or maybe somthing controlled by a -Z switch would be best; I don't like having to drudge through debug logs with lines that are thousands of characters long...

nikomatsakis (Oct 09 2018 at 13:16, on Zulip):

I'm still not sure why we couldn't leverage {:#?} in some way

a couple of reasons

nikomatsakis (Oct 09 2018 at 13:16, on Zulip):

(1) it has a meaning and that meaning is useful

nikomatsakis (Oct 09 2018 at 13:16, on Zulip):

(2) it doesn't give context

nikomatsakis (Oct 09 2018 at 13:16, on Zulip):

(3) it's RSI-inducing to type

davidtwco (Oct 09 2018 at 13:16, on Zulip):

my idea would be to have a PrettyPrint<Context> trait
and lean on specialization

I have this (very outdated and broken) branch from a while ago that did something similar. I think it was when we were doing the region naming code and wanted to be able to inject names into regions being printed inside larger types.

pnkfelix (Oct 09 2018 at 13:16, on Zulip):

(4) its not googleable

davidtwco (Oct 09 2018 at 13:17, on Zulip):

(deleted)

nikomatsakis (Oct 09 2018 at 13:17, on Zulip):

I personally would prefer to write debug!("{}", foo.pp(cx)) and things like that

nikomatsakis (Oct 09 2018 at 13:17, on Zulip):

yes, pp you can search for in the rustc-docs

nikomatsakis (Oct 09 2018 at 13:17, on Zulip):

and find the PrettyPrint trait

nikomatsakis (Oct 09 2018 at 13:17, on Zulip):

hmm

Jake Goulding (Oct 09 2018 at 15:56, on Zulip):

I'm a fan of the general concept of returning specific types that are meant to be printed. It especially makes sense with the context idea.

Last update: Nov 21 2019 at 23:25UTC