compiler-team icon indicating copy to clipboard operation
compiler-team copied to clipboard

Exposing a versioned, semi-stable MIR interface

Open pnkfelix opened this issue 3 years ago • 4 comments

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:

  1. directly extend rustc itself, or
  2. parse the ("unstable, for human debugging purposes only") MIR output generated by the rustc compiler's --emit=mir option.

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

pnkfelix avatar Mar 10 '22 20:03 pnkfelix

Looks like there is no zulip thread yet.

bjorn3 avatar Mar 10 '22 21:03 bjorn3

@bjorn3 it's still a meeting proposal, zulip threads are created only for MCPs I think ?

lqd avatar Mar 10 '22 22:03 lqd

Right

bjorn3 avatar Mar 10 '22 23:03 bjorn3

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

pnkfelix avatar Mar 29 '22 13:03 pnkfelix

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

pnkfelix avatar May 05 '23 15:05 pnkfelix