miri no longer builds after rust-lang/rust#63214
#63219
Assignees
Labels
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
rust-highfive
added
I-nominated
T-compiler
|
The Miri update to fix this is happening in #63162. |
This was referenced Aug 4, 2019
Merged
Centril
added a commit
to Centril/rust
that referenced
this issue
Aug 8, 2019
Miri tests: use xargo to build separate libstd This uses `cargo miri setup` to prepare the libstd that is used for testing Miri, instead of adjusting the entire bootstrap process to make sure the libstd that already gets built is fit for Miri. The issue with our current approach is that with `test-miri = true`, libstd and the test suite get built with `--cfg miri`, which e.g. means hashbrown uses no SIMD, and not all things are tested. Such global side-effects seem like footguns waiting to go off. On the other hand, the new approach means we install xargo as a side-effect of doing `./x.py test src/tools/miri`, which might be surprising, and we also both have to build xargo and another libstd which costs some extra time. Not sure if the tools builders have enough time budget for that. Maybe there is a way to cache xargo? We have to first first land rust-lang/miri#870 in Miri and then update this PR to include that change (also to get CI to test Miri before bors), but I wanted to get the review started here. Cc @oli-obk (for Miri) @alexcrichton (for CI) @Mark-Simulacrum (for bootstrap) Fixes rust-lang#61833, fixes rust-lang#63219
Centril
added a commit
to Centril/rust
that referenced
this issue
Aug 8, 2019
Miri tests: use xargo to build separate libstd This uses `cargo miri setup` to prepare the libstd that is used for testing Miri, instead of adjusting the entire bootstrap process to make sure the libstd that already gets built is fit for Miri. The issue with our current approach is that with `test-miri = true`, libstd and the test suite get built with `--cfg miri`, which e.g. means hashbrown uses no SIMD, and not all things are tested. Such global side-effects seem like footguns waiting to go off. On the other hand, the new approach means we install xargo as a side-effect of doing `./x.py test src/tools/miri`, which might be surprising, and we also both have to build xargo and another libstd which costs some extra time. Not sure if the tools builders have enough time budget for that. Maybe there is a way to cache xargo? We have to first first land rust-lang/miri#870 in Miri and then update this PR to include that change (also to get CI to test Miri before bors), but I wanted to get the review started here. Cc @oli-obk (for Miri) @alexcrichton (for CI) @Mark-Simulacrum (for bootstrap) Fixes rust-lang#61833, fixes rust-lang#63219
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello, this is your friendly neighborhood mergebot.
After merging PR #63214, I observed that the tool miri no longer builds.
A follow-up PR to the repository https://github.com/rust-lang/miri is needed to fix the fallout.
cc @Centril, do you think you would have time to do the follow-up work?
If so, that would be great!
cc @Centril, the PR reviewer, and @rust-lang/compiler -- nominating for prioritization.
The text was updated successfully, but these errors were encountered: