"./miri test" is very slow on repeated executions

[RalfJung]

Running ./miri run --dep multiple times is very slow. The first time I guess it is building parts of Miri or so (./miri run doesn't print any updates about what it does, making this hard to figure out), but the 2nd time it shouldn't have to do any of that -- and yet, it is slow.

Needless to say, this is quite painful when debugging a pass-dep test.

[RalfJung]

It's not just "./miri run". "./miri test" has the same issue.

This was fine until recently, so something must have changed somewhere to break this.

[RalfJung]

I think it has to do with ui_test dependency building.

Repeating "./miri test hello" is fine, but repeating a pass-dep test rebuilds a lot of stuff.

Cc @oli-obk -- somehow it seems like ui_test dependency building is now polluting Miri's own build cache?

[oli-obk]

Huh. We're still on a version from October. I'll investigate

[RalfJung]

Turns out this has been ongoing for a while.
89fe528 is still bad.
d7ccde2 is good.
Regression range: d7ccde2...89fe528

[RalfJung]

Bisecting says this is the bad PR: #3252.
And indeed reverting 431fbc5 fixes the issue.

That did indeed touch the "deps build" logic, by setting RUSTFLAGS to be empty.
But I would assume that is completely isolated from building Miri itself, so why does it lead to rebuilds?

I'll leave it to you to continue here. :)

[bjorn3]

As far as I can tell the RUSTFLAGS are passed to a cargo run of cargo-miri with the same target dir as miri. As such any shared dependencies will see a different RUSTFLAGS between building miri / the regular build of cargo-miri and the cargo run of cargo-miri for the purpose of building the test dependencies. I think it would be possible to fix this by directly running the previously built cargo-miri executable rather than rebuilding it with empty RUSTFLAGS.

[RalfJung]

Oh I see, so the issue isn't that dep builds get mixed with the other builds but that we're re-building cargo-miri inside the dep build...