Repository navigation
round-trippability of HIR pretty printing #60663
Description
Should it be possible to feed the output of --unpretty=hir back to rustc without requiring the user to do any changes? Right now this is only possible for very trivial code, and even then requires adding some feature gates.
Any code with moderately complex expansions will require additional imports or touching the code. Some things I've noticed:
- HIR printing of
async fnis broken #60661 (async fn, probably easily fixed) - HIR printing of
existential typeis broken #60662 (existential type, easily fixed) $crateshows up in paths'_lifetimes where there were inferred lifetimes in signatures before
Activity
oli-obk commentedon May 9, 2019
cc @rust-lang/compiler is this something we should strive to address? Seems a good start for new contributors as it's mostly detective work and trying out stuff.
In order to actually test it we'd need to change compiletest.
compile-passandrun-passtest after pretty printing instead of normally//not-unpretty-hir-roundtrippablethat we'd put on thosecompile-passorrun-passtests that don't work yet.petrochenkov commentedon May 9, 2019
Nah, for HIR pretty-printing there should be no such requirements, IMO.
It just should look reasonable enough to make HIR debugging possible.
(AST pretty printing is another story, proc macros and tools do use it for generating well-formed code, even it it's not entirely reliable due to hygiene etc.)
petrochenkov commentedon May 9, 2019
I mean if some fix is trivial and improves the output, then we should accept it, but if it requires preserving some data in HIR solely for pretty-printing, then we should not.
Mark-Simulacrum commentedon Sep 22, 2019
Closing. I agree that this is not generally desirable, specific (simple) bug fixes can come as PRs; issues are not appropriate (as we don't want it, but don't object to it).