Add -Zjit-mode flag

[bjorn3]

This flag tells the codegen backend to immediately execute the code it builds. This is exactly what miri needs as it is unable to produce real executables. Adding a builtin flag would allow cargo to add native support for this without miri needing to do a bunch of hacks in its cargo wrapper. Furthermore cg_clif also has a jit mode that benefits from it.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[rustbot]

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Urgau]

This is kind-of a nit, but the naming of the flag implies to me that we generate a binary that calls back rustc at runtime to generate the machine code where necessary. What about -Zrun instead? or -Zexecute?

[bjorn3]

What about -Zrun instead? or -Zexecute?

I like those names. I don't have much of a preference which of the two to use.

[RalfJung]

The code for ./miri run in miri-script/src/commands.rs likely also needs to set this new flag.

[RalfJung]

This seems MCP-worthy.

Also, how do you imagine this to work from cargo? Cargo currently treats output from rustc and the program very different: rustc produces JSON output that is fully consumed by cargo, cached, and then rendered to the terminal. The program just gets direct access to the terminal.

[bjorn3]

Cargo currently treats output from rustc and the program very different: rustc produces JSON output that is fully consumed by cargo, cached, and then rendered to the terminal. The program just gets direct access to the terminal.

Cargo currently does forward all lines output on stdout which don't start with a } to the terminal unchanged. A more principled way would be for rustc to emit a message indicating that jit execution starts. Though that would require miri to somehow change the diagnostic emitter to disable json output and force colors at that point.

[RalfJung]

Cargo currently does forward all lines output on stdout which don't start with a }

I assume you mean {.

That said, last time I checked (which was many years ago), it did so in a buffered way, making it unsuitable for Miri (we need to be able to emit partial lines). Also, it's not acceptable for output from the program Miri interprets to be swallowed just because it looks like JSON.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rust-log-analyzer]

The job pr-check-2 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

/dev/sda15      105M  6.2M   99M   6% /boot/efi
tmpfs           1.6G   12K  1.6G   1% /run/user/1001
================================================================================

Sufficient disk space available (94917444KB >= 52428800KB). Skipping cleanup.
##[group]Run echo "[CI_PR_NUMBER=$num]"
echo "[CI_PR_NUMBER=$num]"
shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
---
[RUSTC-TIMING] ui test:false 0.082
error[E0432]: unresolved import `rustc_codegen_ssa::CodegenResults`
  --> src/tools/miri/src/bin/miri.rs:56:25
   |
56 | use rustc_codegen_ssa::{CodegenResults, CompiledModules, CrateInfo, TargetConfig};
   |                         ^^^^^^^^^^^^^^ no `CodegenResults` in the root

warning: unused variable: `sess`
   --> src/tools/miri/src/bin/miri.rs:240:26
    |
240 |     fn target_cpu(&self, sess: &Session) -> String {

[RalfJung]

If this is something Miri will always want to set, cargo-miri is not a great place as it does not cover ./miri run and ./miri test.

The usual way we add flags we always want is here; does that not work?