Improve `ptr_rotate` performance, tests, and benches
The corresponding issue is #61784. I am not actually sure if miri can handle the test, but I can change the commit if necessary.
Test interaction between `async { ... }` and `?`, `return`, and `break`
Per the second checkbox in https://github.com/rust-lang/rust/issues/62121#issuecomment-506884048, test that `async { .. }` blocks:
1. do not allow `break` expressions.
2. get targeted by `return` and not the parent function.
3. get targeted by `?` and not the parent function.
Works towards resolving blockers in #63209.
r? @cramertj
move of packed fields might or might not occur when they actually are sufficiently aligned
See https://github.com/taiki-e/pin-project/pull/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](db7c773a6b/src/librustc_mir/util/alignment.rs (L7)).
gitignore: add comment explaining policy
Based on https://github.com/rust-lang/rust/pull/63307#issuecomment-518539503, I added a comment what I think should be gitignored and what not. This is just a proposal, obviously. Also see https://github.com/rust-lang/rust/pull/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.
Don't recommend `extern crate` syntax
`extern crate` syntax is not a good recommendation any more, so I've changed it to just print a suggested crate name.
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 https://github.com/rust-lang/miri/pull/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 https://github.com/rust-lang/rust/issues/61833, fixes https://github.com/rust-lang/rust/issues/63219
Don't use remap-path-prefix in dep-info files.
This changes it so that dep-info files do not use remapped paths.
Having remapped paths causes problems with Cargo because if you remap to a nonexistent path (like `/rustc/$HASH` which rustc distributions do), then Cargo's change tracking thinks the files don't exist and will always rebuild.
I don't actually know if this is a good idea. I think it makes sense, but I do not know what the exact requirements are for reproducible builds. I consider these files separate from the binary artifacts generated, and as a build-system helper, so it seems reasonable to me.
I'm also not sure if this needs a test. I'll definitely add one on the cargo side if this is merged.
Closes#63329
bump rand in libcore/liballoc test suites
This pulls in the fix for https://github.com/rust-random/rand/issues/779, which trips Miri when running these test suites.
`SmallRng` (formerly used by libcore) is no longer built by default, it needs a feature gate. I opted to switch to `StdRng` instead. Or should I enable the feature gate?
Test conditional initialization validation in async fns
r? @cramertj
Per [paper doc](https://paper.dropbox.com/doc/async.await-Call-for-Tests--AiWF2Nt8tgDiA70qFI~oiLOOAg-nMyZGrra7dz9KcFRMLKJy) calling for async/.await tests, tests are desired for conditionally initialized local variables. This PR hopes to provide tests for that.
#63294 seems to be tracking the items from the paper doc that this PR is related to
#62121 is an open issue asking for more async/.await tests that this relates to
---
👍 executed 2 new tests
👍 tidy
