Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

round-trippability of HIR pretty printing #60663

Closed
oli-obk opened this issue May 9, 2019 · 4 comments
Closed

round-trippability of HIR pretty printing #60663

oli-obk opened this issue May 9, 2019 · 4 comments
Labels
A-HIR Area: The high-level intermediate representation (HIR) A-pretty Area: Pretty printing (including `-Z unpretty`) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@oli-obk
Copy link
Contributor

oli-obk commented May 9, 2019

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:

@oli-obk oli-obk added A-HIR Area: The high-level intermediate representation (HIR) A-pretty Area: Pretty printing (including `-Z unpretty`) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 9, 2019
@oli-obk
Copy link
Contributor Author

oli-obk commented 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.

  1. a way to run all compile-pass and run-pass test after pretty printing instead of normally
  2. to have a new flag //not-unpretty-hir-roundtrippable that we'd put on those compile-pass or run-pass tests that don't work yet.
  3. have some builder run tests with pretty printing (shouldn't be much slower I hope)

@petrochenkov
Copy link
Contributor

is this something we should strive to address?

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
Copy link
Contributor

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
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-HIR Area: The high-level intermediate representation (HIR) A-pretty Area: Pretty printing (including `-Z unpretty`) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants