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
Running ./x.py test miri --stage 0
twice rebuilds miri, cargo-miri, and rustdoc
#123177
Comments
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 |
I've just found this in the rustdoc sources: rust/src/bootstrap/src/core/build_steps/tool.rs Lines 441 to 445 in 7bdd63d
Maybe Miri should do something similar. Then |
That would work actually, it seems to be the right path. |
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. |
Cargo has this to say about why things are rebuilt:
And indeed, rustdoc sets
That's a bit annoying to have this set in the tool, it means each tool needs to repeat the same logic. |
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. |
…-ozkan Refactor the way bootstrap invokes `cargo miri` Instead of basically doing `cargo run --manifest-path=<cargo-miri's manifest> -- miri`, let's invoke the `cargo-miri` binary directly. That means less indirections, and also makes it easier to e.g. run the libcore test suite in Miri. (But there are still other issues with that.) Also also adjusted Miri's stage numbering so that it is consistent with rustc/rustdoc. This also makes `./x.py test miri` honor `--no-doc`. And this fixes rust-lang#123177 by moving where we handle parallel_compiler.
…-ozkan Refactor the way bootstrap invokes `cargo miri` Instead of basically doing `cargo run --manifest-path=<cargo-miri's manifest> -- miri`, let's invoke the `cargo-miri` binary directly. That means less indirections, and also makes it easier to e.g. run the libcore test suite in Miri. (But there are still other issues with that.) Also also adjusted Miri's stage numbering so that it is consistent with rustc/rustdoc. This also makes `./x.py test miri` honor `--no-doc`. And this fixes rust-lang#123177 by moving where we handle parallel_compiler.
Refactor the way bootstrap invokes `cargo miri` Instead of basically doing `cargo run --manifest-path=<cargo-miri's manifest> -- miri`, let's invoke the `cargo-miri` binary directly. That means less indirections, and also makes it easier to e.g. run the libcore test suite in Miri. (But there are still other issues with that.) Also also adjusted Miri's stage numbering so that it is consistent with rustc/rustdoc. This also makes `./x.py test miri` honor `--no-doc`. And this fixes rust-lang/rust#123177 by moving where we handle parallel_compiler.
Refactor the way bootstrap invokes `cargo miri` Instead of basically doing `cargo run --manifest-path=<cargo-miri's manifest> -- miri`, let's invoke the `cargo-miri` binary directly. That means less indirections, and also makes it easier to e.g. run the libcore test suite in Miri. (But there are still other issues with that.) Also also adjusted Miri's stage numbering so that it is consistent with rustc/rustdoc. This also makes `./x.py test miri` honor `--no-doc`. And this fixes rust-lang/rust#123177 by moving where we handle parallel_compiler.
Refactor the way bootstrap invokes `cargo miri` Instead of basically doing `cargo run --manifest-path=<cargo-miri's manifest> -- miri`, let's invoke the `cargo-miri` binary directly. That means less indirections, and also makes it easier to e.g. run the libcore test suite in Miri. (But there are still other issues with that.) Also also adjusted Miri's stage numbering so that it is consistent with rustc/rustdoc. This also makes `./x.py test miri` honor `--no-doc`. And this fixes rust-lang/rust#123177 by moving where we handle parallel_compiler.
This is fairly easy to reproduce:
(The
--test-args
just serves to make this take less long.)The second command shouldn't have to build anything, just run the tests. But somehow it actually rebuilds miri, cargo-miri, and rustdoc.
This is a recent regression introduced by #123028. Somehow building rustdoc seems to destroy the build cache for miri and cargo-miri, and vice versa.
Cc @onur-ozkan
The text was updated successfully, but these errors were encountered: