Exposing a versioned, semi-stable MIR interface
Meeting proposal info
- Title: Exposing a versioned, semi-stable MIR interface
- Type: technical
Summary
Various stakeholders are using MIR as the basis for tools that integrate with Rust. The rustc LLVM and cranelift backends are the foremost MIR users, but there is also the Miri interpreter, as well as verification tools like kani and crux-mir; they are all using MIR as their fundamental input to describe a given program.
Today, the options for taking MIR as input are either:
- directly extend
rustcitself, or - parse the ("unstable, for human debugging purposes only") MIR output generated by the
rustccompiler's--emit=miroption.
Neither of these options is particularly good. For example, we could do better by providing a stand-alone crate that defines a versioned specification for MIR, with support for parsing, emitting, and potentially some standard transformations and analyses.
This meeting proposal is for us to discuss our options here, with questions like:
- What can we do to enable the work like that above?
- Are we ready to work on a standalone definition of MIR? (What are the risks in agreeing to this?)
- Who wants to own the effort? Who are the stakeholders that should be involved?
See also:
- https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2021-02-17-Increasing-Trust-in-Rust-Compiler.md
About this issue
This issue corresponds to a meeting proposal for the compiler team steering meeting. It corresponds to a possible topic of discussion. You can read more about the steering meeting procedure here.
Comment policy
These issues are meant to be used as an "announcements channel" regarding the proposal, and not as a place to discuss the technical details. Feel free to subscribe to updates. We'll post comments when reviewing the proposal in meetings or making a scheduling decision. In the meantime, if you have questions or ideas, ping the proposers on Zulip (or elsewhere).
Looks like there is no zulip thread yet.
@bjorn3 it's still a meeting proposal, zulip threads are created only for MCPs I think ?
Right
This meeting occurred; it was driven on Zulip at https://zulip-archive.rust-lang.org/stream/238009-t-compiler/meetings/topic/.5Bsteering.20meeting.5D.202022-03-25.20compiler-team.23488.2C.20.23498.html
We had the meeting on 2022-03-25
We discussed this doc: https://hackmd.io/naxjPGp3SL-5EIOjIknCfQ?view
The public zulip archive serves as the meeting record: https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bsteering.20meeting.5D.202022-03-25.20compiler-team.23488.2C.20.23498/near/276622720