Split out the stable part of smir into its own crate to prevent accidental usage of forever unstable things #115934
Conversation
rustbot
added
A-meta
This comment has been minimized.
This comment has been minimized.
oli-obk
force-pushed
the
smir_identity
branch
from
6a7c91b
to
6a6c2f4
Compare
|
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. This PR changes Stable MIR cc @oli-obk, @celinval, @spastorino |
compiler/smir/README.md
Outdated
| - `stable_mir`: Public crate, to be published on crates.io, which will contain | ||
| the stable data structure as well as proxy APIs to make calls to the | ||
| compiler. | ||
| - `rustc_smir`: The compiler crate that will translate from internal MIR to |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
oli-obk
force-pushed
the
smir_identity
branch
from
6a6c2f4
to
1bc8681
Compare
|
☔ The latest upstream changes (presumably #116117) made this pull request unmergeable. Please resolve the merge conflicts. |
oli-obk
force-pushed
the
smir_identity
branch
from
1bc8681
to
a38e983
Compare
This comment has been minimized.
This comment has been minimized.
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 4 pull requests Successful merges: - rust-lang#115934 (Split out the stable part of smir into its own crate to prevent accidental usage of forever unstable things) - rust-lang#116149 (Anonymize binders for `refining_impl_trait` check) - rust-lang#116178 (Add test for `const async fn`) - rust-lang#116187 (Add context to `let: Ty = loop { break };`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#115934 - oli-obk:smir_identity, r=spastorino Split out the stable part of smir into its own crate to prevent accidental usage of forever unstable things Some groundwork for being able to work on rust-lang/project-stable-mir#27 at all r? `@spastorino`
Some groundwork for being able to work on rust-lang/project-stable-mir#27 at all
r? @spastorino