r? @varkor

(rust-highfive has picked a reviewer for you, use r? to override)

Happy to go through the MCP process if you think it would be helpful, not sure what the procedure is for unstable flags.

I haven't seen anyone using it.

The Rust Playground uses it:

~/rust-playground master
❯ rg -- --pretty
ui/src/sandbox.rs
402:            "--pretty=expanded",

@varkor I saw you marked this as waiting on author - do you want me to fix CI first? Or does that mean you think removing the flag is a bad idea?

@jyn514: it seemed the premise of the change was in question, as @camelid pointed out that the flag currently is used. Maybe it would be best to remove the use in the Playground before going ahead with removal altogether?

@rust-lang/compiler @rust-lang/compiler-contributors: does know of any reason --pretty is worth keeping around? It seems like this option is subsumed by --unpretty, but perhaps there's some subtlety.

@jyn514: if no-one objects, the changes look good to me.

Meanwhile we are at this, couldn't (on a different PR of course) we also propose to rename unpretty to something more meaningful?. I've seen a bunch of people confused about it and I also was confused at some point.

I mean, we could change --unpretty to pretty and remove unpretty if you like. Not sure if you think that's more clear.

(cc @shepmaster regarding play)

I don't really have a clear picture of the differences behind these flags, but I think that consolidating seems fine, or perhaps just make one an alias for the other. I think it's pretty amusing that Rust has "unpretty printing" myself :)

Does it really work like a pretty printer in most cases? or is it more like a dump-* kind of thing?

Does it really work like a pretty printer in most cases? or is it more like a dump-* kind of thing?

I think most of the formats are just for debugging, not pretty-printing.

    -Z                       unpretty=val -- present the input source, unstable (and less-pretty) variants;
        valid types are any of the types for `--pretty`, as well as:
        `expanded`, `expanded,identified`,
        `expanded,hygiene` (with internal representations),
        `everybody_loops` (all function bodies replaced with `loop {}`),
        `ast-tree` (raw AST before expansion),
        `ast-tree,expanded` (raw AST after expansion),
        `hir` (the HIR), `hir,identified`,
        `hir,typed` (HIR with types for each node),
        `hir-tree` (dump the raw HIR),
        `mir` (the MIR), or `mir-cfg` (graphviz formatted MIR)

@jyn514 right, that's what I meant, then maybe dump or something else is more precise than pretty/unpretty.

remove the use in the Playground

I'm fine removing it, but the playground CI cannot run now because rustfmt is broken. When it unbreaks, I plan to merge the change.

Rustfmt should have been fixed in #84886.

1. So, in my opinion, the distinction between --pretty and --unpretty is that the options under --pretty are meant to be meaningful to Rust programmers, while the options under --unpretty are solely meaningful to rustc developers.

   • I don't know if that distinction currently holds, but it was what was in my head at the time that I added --unpretty.

2. I also had a vague thought that --pretty, or some subset of it, would be on the path to eventual stabilization. Is that a non-starter at this point? (Or is it an irrelevant question, in the sense that a subset of any flag could be stabilized, and the issue here is whether it makes sense to have two flags...)

I definitely would think it strange to keep a flag named --unpretty if we did not have a --pretty flag that the former is referencing. But it sounds like the conversation here is suggesting that we would rename --unpretty to --pretty, or to --dump, et cetera...

Anyway, I don't know. I think there's value in having two variants, but I suspect I'm in the minority here.

I'll remove the S-waiting-on-team label to signal that this PR can move forward (discussion)

@rustbot label -S-waiting-on-team

Also, I kind of wonder what the point of --pretty=normal is - I kind of expect it to be the same as running rustfmt, but it is definitely not that.

Rust has it's own "pretty" printer. --pretty=normal runs the source through it without doing anything else. I put "pretty" in quotes as it is anything but pretty. It does match the old style of rust a bit though with visual indentation instead of block indentation.

Another alternative @nikomatsakis / @Mark-Simulacrum thought of in the meantime is to actually use rustfmt as a library for pretty-printing; that should be feasible now that it's in-tree: https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/rustdoc.20is.20using.20rustc_ast_pretty.2C.20would.20.E2.80.A6.20compiler-team.23403/near/225171876

@jyn514 I retract the objection I voiced above. I'll go ahead and take a look.

@bors r+

📌 Commit 23bbd65 has been approved by pnkfelix

⌛ Testing commit 23bbd65 with merge 7d6bf86...

☀️ Test successful - checks-actions
Approved by: pnkfelix
Pushing 7d6bf86 to master...