Running `./x.py test miri --stage 0` twice rebuilds miri, cargo-miri, and rustdoc about rust HOT 7 CLOSED

Building rustdoc using the stage 1 compiler causes this, which is weird. I suspect that previously invoked miri related steps may have broken the cache somehow. Or we may need to improve/enhance Builder::ensure.

from rust.

I've just found this in the rustdoc sources:

Maybe Miri should do something similar. Then ./x.py test miri should also Do The Right Thing without adding --stage 0 (since actually stage 1 would be the right stage to use). And maybe then the rebuilding issue also vanishes. Or maybe that's unrelated, not sure.

from rust.

That would work actually, it seems to be the right path.

from rust.

Unfortunately it doesn't help. We probably still should do it.

But somehow building rustdoc seems to delete the build cache for Miri and cargo-miri, and vice versa.

from rust.

Cargo has this to say about why things are rebuilt:

       Dirty libc v0.2.153: the rustflags changed

And indeed, rustdoc sets

cargo.rustflag("--cfg=parallel_compiler");

That's a bit annoying to have this set in the tool, it means each tool needs to repeat the same logic.

from rust.

iirc rustdoc sets that to not dirt the compiler builds, we should probably handle that more globally.

from rust.

iirc rustdoc sets that to not dirt the compiler builds, we should probably handle that more globally.

Yup, that's what the last commit in #123192 does now.

from rust.