You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RalfJung opened this issue
Feb 25, 2024
· 3 comments
Labels
A-metaNot about any part of Miri per se, but about shaping the environment to make something in/with MiriC-projectCategory: a larger project is being tracked here, usually with checkmarks for individual steps
@shepmastersuggested we should ship Miri on stable, and the general reception was positive. What needs to be done to make that happen?
Figure out the process. Which teams even need to be involved? Probably the compiler team, primarily. And the release team to update the release machinery?
Update docs where needed. The README still calls Miri an "experimental interpreter", which does not sound right for a tool shipped on stable.
Make sure -Zmiri flags cannot be used on stable. We're "parsing" these very early in the Miri binary, can we even figure out at that moment whether we are on stable yet?
Decide which of the -Zmiri flags we want to expose on stable, and how. Just make them -Cmiri? Or is there something better?
Make the magic miri_* extern functions not available on stable. Can we somehow require that the crate calling them must have a particular feature gate or so?
On stable, either skip doctests or figure out if we can still somehow use --runtool and --test-builder.
The Miri driver currently passes some flags to rustc to change the configuration a bit. Most of these are unstable so this strategy does not work on stable. Instead we should programmatically change the flags so we don't have to go through argument parsing and can bypass the stability check.
Does the way we build the sysroot even work on stable? We'd have to set RUSTC_BOOTSTRAP; that requires t-compiler approval.
Anything else that I missed?
The text was updated successfully, but these errors were encountered:
RalfJung
added
the
C-project
Category: a larger project is being tracked here, usually with checkmarks for individual steps
label
Feb 25, 2024
I think a good way to go about the flags would be to do something similar to the other Rust tools. That is to have a toml file for setting config options. I would make it similar to the relationship of cargo and rustc, and only have the toml file read when cargo-miri is used, then also have the -C flags available as well through the miri binary & MIRIFLAGS.
Whether that is miri's own custom toml, or a new table of the cargo.toml (like #2451) I'm not sure.
Being able to set Miri's flags from a config file is tracked at #2347; I don't think this is blocking or blocked on stabilization. We only have to figure out the names for the flags understood by miri itself here; support in cargo-miri can come later IMO.
We are using rustdoc -Zunstable-options to make doctests work (specifically we need --runtool and --test-builder). So it looks like currently, on stable cargo miri would have to skip doctests.
RalfJung
added
the
A-meta
Not about any part of Miri per se, but about shaping the environment to make something in/with Miri
label
May 3, 2024
A-metaNot about any part of Miri per se, but about shaping the environment to make something in/with MiriC-projectCategory: a larger project is being tracked here, usually with checkmarks for individual steps
@shepmaster suggested we should ship Miri on stable, and the general reception was positive. What needs to be done to make that happen?
-Zmiri
flags cannot be used on stable. We're "parsing" these very early in the Miri binary, can we even figure out at that moment whether we are on stable yet?-Zmiri
flags we want to expose on stable, and how. Just make them-Cmiri
? Or is there something better?miri_*
extern functions not available on stable. Can we somehow require that the crate calling them must have a particular feature gate or so?--runtool
and--test-builder
.RUSTC_BOOTSTRAP
; that requires t-compiler approval.The text was updated successfully, but these errors were encountered: