Split out the stable part of smir into its own crate to prevent accidental usage...

It would be nice to continue the parallels to proc macros here. Is this crate like proc_macro, exposing a stable but not super nice API?

not sure yet. We may add a proc-macro style intermediate API at some point

for now this is just a "we don't break you that often, and if we do, we have a transition API so you have a few months of grace period"-crate

How exactly is that supposed to work? I don't entirely follow. So rustc_smir will try to maintain a compat when things change in rustc? And only change things after a while? And stable_mir will access this compat layer but then after a toolchain upgrade with notice it will stop working because rustc_smir changed? What's the point of having stable_mir on crates.io then if it depends on the compiler version anyways?

We're trying to figure this out. As the initial version I will add derives to the 0.1 release that then do 1:1 conversions from the unstable rustc version to the 0.1 version. When we plan a breaking change, we create a 0.2 version that does 1:1 conversion with an unstable equivalent. The 0.1 crate will get its compat layer changed to instead refer to the 0.2 crate and convert from 0.2 to 0.1 (semver trick).

Very vague and handwavy I know.

The alternative is to go the proc-macro route and just have a bunch of extern "C" functions to communicate with the compiler in a stable way, but I haven't given that too much thought yet, as the above mentioned system would be enough for most folk currently using unstable MIR