Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ship Miri on stable toolchains #3322

Open
9 tasks
RalfJung opened this issue Feb 25, 2024 · 3 comments
Open
9 tasks

Ship Miri on stable toolchains #3322

RalfJung opened this issue Feb 25, 2024 · 3 comments
Labels
A-meta Not about any part of Miri per se, but about shaping the environment to make something in/with Miri C-project Category: a larger project is being tracked here, usually with checkmarks for individual steps

Comments

@RalfJung
Copy link
Member

RalfJung commented Feb 25, 2024

@shepmaster suggested 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?
@RalfJung RalfJung added the C-project Category: a larger project is being tracked here, usually with checkmarks for individual steps label Feb 25, 2024
@RossSmyth
Copy link
Contributor

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.

@RalfJung
Copy link
Member Author

RalfJung commented Feb 27, 2024

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.

@RalfJung
Copy link
Member Author

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 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-meta Not about any part of Miri per se, but about shaping the environment to make something in/with Miri C-project Category: a larger project is being tracked here, usually with checkmarks for individual steps
Projects
None yet
Development

No branches or pull requests

2 participants