Improve typed pretty printing

[nrc]

Currently you can use --unpretty=hir,typed to print out the HIR with type annotations in comments. This could be vastly improved so that it is actually a useful for the user:

• use type ascription rather than comments
• map the types back from the HIR to the AST
• use the original program's formatting (or if that isn't possible, use rustfmt, rather than the pretty printer)
• output only a specified portion of the program, rather than the whole program

If we do all of those things, then this should probably be a tool external to the compiler. The first item could just fix --unpretty=hir,typed, the second could provide --unpretty=typed.

[sgrif]

I'd be interested in working on this, I've been looking to get more involved w/ the compiler.

[nrc]

@sgrif great! So, to get you started, we do pretty printing in pretty.rs. Look for PpmTyped. TypedAnnotation is what actually adds the comments to the output.

I think the best way to start is by implementing a Fold which takes a HIR and transforms it into a new HIR with every expression wrapped in a type ascription expression, with the type found from the type checking info (if you look at the way that pretty printing finds the type, you should be able to do the same thing).

Then pretty printing typed should just pretty print that HIR like a normal HIR and you can remove TypedAnnotation (unless there are expressions where we can't add add ascription wrappers, in which case we'd need to keep comments for those cases).

Let me know if you have questions. (You can ping me on irc, I'm nrc there too)

[imjacobclark]

@nrc I'd like to pick this up - I haven't worked on any compiler internals before, could we grab some time in IRC to go over this? My handle is imjacobclark in IRC too.

[cseale]

@nrc is this being looked at? It looks like it might be easy enough for someone looking to get involved in Rust? I'm trying to gain knowledge and experience on compilers

[nrc]

@cseale I don't think so. Please feel free to jump on this. I would only try to use type ascription rather than comments to start with. My above comment should get you started. Let me know if you have any questions.

[hdelva]

Is this still being worked on? If not, I'd like to give it a shot. Looks like there's a lot of code I'd have to familiarize myself with though.

[nrc]

@erandur it is not, afaik. If you are interested in working on pretty printing, but don't want to wrestle with the compiler, then you might be interested in rustfmt

[ConnorGray]

Is work still being done on this by @erandur ? If not, I'd like to work on this. I'm experienced with Rust, but I've not done work on the compiler before.

@nrc, has your advice above changed much in the last year?

[hdelva]

The cycle continues, I overestimated the amount of free time I was going to have. It's all yours if you want it, I'd love to see the solution.

[PramodBisht]

Checking this.

[steveklabnik]

Triage: not aware of anyone working on this.

[Baranowski]

EDIT: ignore this comment. Apparently functionality (2) is already provided by the racer tool, and functionality (1) soon will be as per the PR for the racer tool: https://github.com/racer-rust/racer/pull/730/files

This sounds quite similar to a functionality I really wished I had when I was recently working on my first rustc patch. Namely, I would love a tool or tools that:

1. For a given position in a file print out the type of the expression at that position.
2. For a given position in a file print out the span of the definition of the variable/method/function at that position.

(1.) is inspired by hdevtools used in Haskell development. It integrates really nicely with vim, turning the editor into a powerful IDE. For a language with type inference and such a robust type system I find it to be a huge productivity booster and a headache preventive medicine.

(2.) is in reaction to how poorly ctags works for Rust. Mostly because most methods are trait implementations and vim sends me to one of many implementations of that trait, rarely the one I really want to see. This is even worse in rustc development since the names are (rightly!) reused between the many crates that rustc consists of.

I think as a first PoC/MVP such a tool could be simply a program that for each request generates types/definition spans from scratch for the entire crate but prints only one of them. It would be slow, but still faster than my current workflow of grepping and manually navigating the results list. At a later stage it could be turned into a daemon just like hdevtools, for a shorter response time and a better user experience.

I would be happy to tackle this. Does the above make sense? I would appreciate some criticism. Since I'm a newcomer to Rust and rustc, perhaps there is already a workflow that eliminates the need for such a tool and I'm simply not aware of it.