Miri tests: use xargo to build separate libstd #63162
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
This was referenced Jul 31, 2019
|
This seems fine to me, especially as it looks to be consolidating miri testing related logic which is good! I think it'd be good to get a green light from Azure as well, but once the miri update is included that should auto-test here anyway. |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Wait, why did this code now run in the It says "Building stage2 tool miri", and still seems to try to test. |
Mark-Simulacrum
approved these changes
Aug 2, 2019
|
@bors rollup=never |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
@Mark-Simulacrum any idea why the The tools builder also fails, I am investigating that. |
|
That builder runs tests? |
|
But I thought the tools tests should only be run on the tools builder? |
|
I've spent a bit of time trying to investigate, and something feels off to me. This auto branch build does not build miri on the x86_64-gnu-llvm-6.0 builder. Neither does this recent PR build; the failure in this PR though clearly shows miri being built. AFAICT, this is because Miri is labeled as "default" = true, unlike all the other tools (Clippy, etc.) This usually didn't matter because we had test_miri as a condition, but since that has gone away, this PR needs to change miri to no longer be enabled by default, by removing or flipping the value of |
This comment has been minimized.
This comment has been minimized.
|
@Mark-Simulacrum nice catch, thanks! |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
Testing only on the tools job seems to work, at least. ;) Building Miri fails because master is currently broken with Miri. |
|
@bors: r+ |
|
📌 Commit 77028562fc02b3dd2222adbaec94daa9feba1f2f has been approved by |
bors
added
S-waiting-on-bors
|
Or well, @bors: r- delegate+ r=me when this is ready |
|
@bors r=alexcrichton |
|
📌 Commit e6be1d7 has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang/miri
that referenced
this pull request
Aug 8, 2019
Cleanup after rustc bootstrap tests Miri with a separate libstd Should only be merged after rust-lang/rust#63162 got the green light.
|
⌛ Testing commit e6be1d7 with merge a430e789d93814093d5f4889a5bcdee977f9aa75... |
Centril
added a commit
to Centril/rust
that referenced
this pull request
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
|
@bors retry rolled up. |
|
⌛ Testing commit e6be1d7 with merge d58ca014d15e3523965f8a7a46f94d1a4ceb5166... |
Centril
added a commit
to Centril/rust
that referenced
this pull request
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
|
@bors retry rolled up. |
bors
added a commit
that referenced
this pull request
Aug 8, 2019
Rollup of 6 pull requests Successful merges: - #63162 (Miri tests: use xargo to build separate libstd) - #63289 (Don't recommend `extern crate` syntax) - #63373 (gitignore: add comment explaining policy) - #63374 (move of packed fields might or might not occur when they actually are sufficiently aligned) - #63381 (reduce visibility) - #63387 (Test interaction between `async { ... }` and `?`, `return`, and `break`) Failed merges: r? @ghost
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This uses
cargo miri setupto 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 #61833, fixes #63219