-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Rollup of 5 pull requests #63389
Rollup of 5 pull requests #63389
Conversation
… sufficiently aligned
Co-Authored-By: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
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
…richton Sort the fat LTO modules to produce deterministic output. Some projects that use LTO for their release builds are not reproducible. We can fix this by sorting the fat LTO modules before using them. It might also be useful to do this for thin LTO, but I couldn't get that to work to test it so I didn't do it.
gitignore: add comment explaining policy Based on rust-lang#63307 (comment), I added a comment what I think should be gitignored and what not. This is just a proposal, obviously. Also see rust-lang#53768 for some more discussion. The summary is that if there are junk files that you create locally and are fine leaving around (such as `mir_dump`), git has the option for you to add them to `.git/info/exclude`. Others might prefer to keep their working dir clean of those same junk files, so we shouldn't just ignore them for everyone. I then also cleaned up a few more things, but there were many things that I had no idea where they came from so I didn't touch them.
move of packed fields might or might not occur when they actually are sufficiently aligned See taiki-e/pin-project#34, where it was pointed out that we actually don't move fields of 1-aligned types when dropping a packed struct -- but e.g. in a `packed(2)` struct, we don't do something similar for 2-aligned types. The code for that is [here](/~https://github.com/rust-lang/rust/blob/db7c773a6be2f050d1d1504763819ea3916f5428/src/librustc_mir/util/alignment.rs#L7).
reduce visibility r? @petrochenkov
@bors r+ p=5 rollup=never |
📌 Commit 66657e7 has been approved by |
⌛ Testing commit 66657e7 with merge 0a27afaa8515fa8ebd703a7acad956dc17b3731b... |
💔 Test failed - checks-azure |
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 |
Successful merges:
Failed merges:
r? @ghost