minor improvements on running miri

[onur-ozkan]

It should be clear from the commit messages when reviewing them one by one.

[rustbot]

r? @clubby789

rustbot has assigned @clubby789.
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

[onur-ozkan]

I assume Ralf uses this API a lot, it's worth pinging him to make sure he will be aware of this change (especially the second commit as the first one doesn't affect anything on the user side).

cc @RalfJung

[RalfJung]

I have no idea what the first commit does from a user perspective. The second commit looks good, except for the comment I added. :)

[clubby789]

Yes second commit also lgtm but I'm not sure of what the first is doing 😅

[onur-ozkan]

Yes second commit also lgtm but I'm not sure of what the first is doing 😅

Sure. r? bootstrap

[Kobzol]

The test implementation for Miri uses (stage, host) here. Shouldn't it be unified with this change?

Also, could you please explain what this change does? And add a comment to the code to make it easier to understand in the future.

I tried this with ./x run miri --stage 1 --dry-run --host x86_64-unknown-linux-none.

• On master, the build compiler for miri is stage0/-gnu, while the target compiler is stage1/-gnu.
• With this PR, the build compiler for miri is stage 0/-gnu, while the target compiler is stage1/-none.

So it seems like this changes behavior.

[onur-ozkan]

The test implementation for Miri uses (stage, host) here. Shouldn't it be unified with this change?

It's not really specific to Miri, this approach is used in other Rustc tools as well. It's fairly straightforward and I am not sure creating another function would make it any simpler.

Also, could you please explain what this change does? And add a comment to the code to make it easier to understand in the future.

I tried (17d27c9) to make it less complicated. Let me know if it's simpler to understand now.

I tried this with ./x run miri --stage 1 --dry-run --host x86_64-unknown-linux-none.

• On master, the build compiler for miri is stage0/-gnu, while the target compiler is stage1/-gnu.
• With this PR, the build compiler for miri is stage 0/-gnu, while the target compiler is stage1/-none.

So it seems like this changes behavior.

You can use this patch and see that compilers are still the same:

diff --git a/src/bootstrap/src/core/build_steps/run.rs b/src/bootstrap/src/core/build_steps/run.rs
index 6cf88278d79..81d6218ccaa 100644
--- a/src/bootstrap/src/core/build_steps/run.rs
+++ b/src/bootstrap/src/core/build_steps/run.rs
@@ -133,8 +133,12 @@ fn run(self, builder: &Builder<'_>) {
         }

         let compiler = builder.compiler(stage, target);
+        let host_compiler = tool::get_tool_rustc_compiler(builder, compiler);
         let miri_build = builder.ensure(tool::Miri { compiler, target });

+        assert_eq!(miri_build.target_compiler, compiler);
+        assert_eq!(miri_build.build_compiler, host_compiler);
+
         // Get a target sysroot for Miri.
         let miri_sysroot =
             test::Miri::build_miri_sysroot(builder, miri_build.target_compiler, target);

It's just the stage shifting logic is now fully controlled by tool::Miri. There may be some additional logic handled within tool::Miri (which are mostly good to have), but the overall outcome should remain the same.

[Kobzol]

@bors r+

[bors]

📌 Commit 17d27c9 has been approved by Kobzol

It is now in the queue for this repository.