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

Dump the AST without converting to JSON #37873

Closed
spinda opened this issue Nov 19, 2016 · 3 comments
Closed

Dump the AST without converting to JSON #37873

spinda opened this issue Nov 19, 2016 · 3 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) C-feature-request Category: A feature request, i.e: not implemented / a PR.

Comments

@spinda
Copy link

spinda commented Nov 19, 2016

Like #10485, but using Rust's pretty-printed debug output ({:#?}) instead of a JSON encoding. This would be much easier for a human to read when trying to visualize how rustc interprets a particular syntax element (like I am right now). It could also be easily added to play.rust-lang.org as an additional output target, alongside the current ASM, LLVM IR, and MIR options. The output format wouldn't need to be stable or standardized, this would just be a debugging tool.

I imagine this would entail two additional -Z options, ast and ast-noexpand, to match ast-json and ast-json-noexpand. Am up for preparing a PR if one would be welcomed, implementation appears straightforward at first glance.

@Nemikolh
Copy link

@Mark-Simulacrum
Copy link
Member

It looks like @spinda's PR for this almost went in but was blocked and eventually closed because statements didn't debug print quite as helpfully as desired. I don't know whether the debug statement printing is still the case. This issue seems reasonable (and I guess something we, in general, want) so I'm going to keep open. If anyone would like to implement, I think the suggestions I'd have is to look at #38083 (@spinda's PR) and then see if we can modify the debug statements as suggested there -- in particular, making them not pretty print. I'd remove the debug impls to make auditing the cases easier; then re-add them to support this PR. Arguably, the most "correct" thing would probably be to just change all of the current {:?} to {} for the pretty printing of statements, though I can imagine this being difficult due to being a passed-down state from above somewhere.

@Mark-Simulacrum Mark-Simulacrum added the A-frontend Area: Compiler frontend (errors, parsing and HIR) label May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 26, 2017
@Mark-Simulacrum
Copy link
Member

In hindsight this seems pretty unlikely as something we actually want to keep an issue open for, since implementing it isn't something we actively want to pursue (though, after some discussion on internals if there's interest I think a PR could be accepted).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) C-feature-request Category: A feature request, i.e: not implemented / a PR.
Projects
None yet
Development

No branches or pull requests

3 participants