Teach rustc --emit=mir

[shepmaster]

I'm opening this PR to discuss:

1. Is this a good idea?
2. Is this a good implementation?

I'm sure people will have opinions on both points!

This spawned from #31847 (comment), so I figured a prototype implementation could help provide a seed to talk about.

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[nikomatsakis]

cc @rust-lang/compiler

[nikomatsakis]

So this seems to fall under a broad category of options that we currently confine to -Z but which I think we may want to expose on stable. I'd classify these as "debugging" or "educational" options -- these would include things like the pretty-printer, dumping MIR, profiling information, or other ways to view internal compiler state. The common thread here is that the output would be completely unstable and subject to change -- that is, it is meant for human viewers only (e.g., like diagnostics output).

I sort of suspect that such a family of options should have their own header (rather like -C), and not be conflated with things like --emit, which are used to produce (primarily, anyway) output that can be fed into other tools.

[shepmaster]

I'd classify these as "debugging" or "educational" options

This seems like a reasonable categorization.

the output would be completely unstable and subject to change

Absolutely.

I sort of suspect that such a family of options should have their own header (rather like -C)

This makes sense to me

not be conflated with things like --emit, which are used to produce (primarily, anyway) output that can be fed into other tools.

I suspect I fall into the target group of that "primarily" 😇 . My personal stake is that I'd like to have a stable and unified way of accessing the final MIR, ASM, and LLVM-IR for the playground. In that context, all three of these are debugging/educational, often for the purposes of "how does that look when optimized?".

[eddyb]

We could probably find a better name for --pretty (or rather, --unpretty).
In fact, we have --print which can output a dozen useful strings.
What if we gave that -P and also used it for pretty-printing? That is, -P pretty-source or something.

[nikomatsakis]

@eddyb seems reasonable to me. I'm also not opposed to using --emit for this purpose, I guess, but it does seem like there is a definite distinction between "object code" and "MIR" or "pretty-printed HIR".

[nikomatsakis]

So I was looking into --print. The current list of things to print seems (to me) to be targeting tool consumption, right?

    --print [crate-name|file-names|sysroot|cfg|target-list|target-cpus|target-features|relocation-models|code-models|target-spec-json]
                        Comma separated list of compiler information to print

Is that then the right option? Does it matter if we mix "tool"-targeting things from "human"-targeting things under one option? It feels like it will encourage misuse, but perhaps not.

[alexcrichton]

FWIW --print is generally "this goes to stdout" where --emit is "this goes to a file", and this seems like it's intending to be the latter?

[nikomatsakis]

@alexcrichton I definitely agree --print is better than --emit. Just wondering if it's the right thing to use, in terms of discouraging people from casually thinking the output is stable. Maybe it's good enough.

[nikomatsakis]

Or maybe those things aren't especially stable either?

[alexcrichton]

I'd personally be ok with a giant header comment saying "THIS OUTPUT IS NOT STABLE IT'S JUST MEANT FOR DEBUGGING, IT WILL CHANGE WITHOUT NOTIFICATION" or something like that.

[nikomatsakis]

@alexcrichton where would such a comment go? Would it apply to all the things that --print uses?

Right now the full list shows up in --help. I was thinking maybe it should not, and we should instead have some way to get the list. This list could then make clear (perhaps with an asterix) those items where the output format is not, and will likely never be, stable. But at the end of the day I kind of just feel is has to be written somewhere that is not TOO obscure, and it's fine. Which I think is your point.

[alexcrichton]

Oh sorry I misread what you preferred. I assumed that you preferred --emit (like me) in which case such a comment would go in the file.

If you prefer --print then yeah there's not really a place for such a comment.

[nikomatsakis]

@alexcrichton oh, like, put it in the output itself? That's...kind of a good idea. =)

[nikomatsakis]

Just add something like to the front:

// WARNING: This output format is intended for human consumers only
// and is subject to change without notice. Knock yourself out.

Regarding --emit vs --print I don't honestly care that much.

[alexcrichton]

@nikomatsakis precisely yeah (that's what I was thinking)

[nikomatsakis]

@alexcrichton I actually really like that =)

[nikomatsakis]

@rfcbot fcp merge

I propose we adopt @alexcrichton's suggestion here, and support --emit mir (and other such unstable-y things) but we prefix the output with some comments warning people from relying on any particular detail of the format. We can do the same with the pretty printer, etc. (Feel free to object if you prefer something other than --emit or have any other concerns. I'm just trying to move things along here.)

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

• @Aatch
• @arielb1
• @bkoropoff
• @dotdash
• @eddyb
• @michaelwoerister
• @nikomatsakis
• @nrc
• @pnkfelix

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[shepmaster]

Because I found it equally amusing and informative, I added @nikomatsakis suggested phrasing verbatim.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[bors]

☔️ The latest upstream changes (presumably #39628) made this pull request unmergeable. Please resolve the merge conflicts.

[shepmaster]

Nothing scarier than your little ol' PR getting a merge conflict from a hulking +2,797 −3,169 PR. Thankfully, it didn't seem to have any actual conflicts...

[bjorn3]

To prevent tools from using this you could put spaces/dots/underscores at random places.

[eddyb]

@bjorn3 Any half-decent lexer can remove extra spaces, and if it impedes a lexer, it also does humans.

[nikomatsakis]

@shepmaster travis fails: https://travis-ci.org/rust-lang/rust/jobs/213231773#L1150

[shepmaster]

@nikomatsakis thank you for the heads up. The build is green again.

[nikomatsakis]

Mm I'm going to r+ even though the FCP has not yet expired. I think we've had enough time here.

[nikomatsakis]

@bors r+

[bors]

📌 Commit 4ddedf7 has been approved by nikomatsakis