Implement normalize_erasing_regions queries in terms of 'try' version
Attempt to lessen performance regression caused by https://github.com/rust-lang/rust/pull/91255
r? `@jackh726`
Fix#91306 by deriving all access from a single *mut T
Fixes#91306.
The previous code is invalid because the first argument to `copy_nonoverlapping` is invalidated by the mutable borrow taken out to construct the second argument.
I believe this patch fixes that, and this code should now pass Miri with `-Ztag-raw-pointers`, ~~but I'm currently stuck trying to run my reproducer with a this patched version of the standard library (alternatively, running Miri on the standard library tests itself would suffice).~~ Ralf walked me through this on Zulip.
I've also added fixes for 7 more problems other than those I reported. Most of them are easy to hit by calling sort_unstable on random arrays. I don't have reproducers for every change, but they seem pretty clear-cut to me. But I did only start learning stacked borrows 2 days ago so that might be a large dash of Dunning-Kruger.
Add `io::Error::other`
This PR adds a small utility constructor, `io::Error::other`, a shorthand for `io::Error::new(io::ErrorKind::Other, err)`, something I find myself writing often.
For some concrete stats, a quick search on [grep.app](https://grep.app) shows that more than half of the uses of `io::Error::new` use `ErrorKind::Other`:
```
Error::new\((?:std::)?(?:io::)?ErrorKind:: => 3,898 results
Error::new\((?:std::)?(?:io::)?ErrorKind::Other => 2,186 results
```
Most of these problems originate in use of get_unchecked_mut.
When calling ptr::copy_nonoverlapping, using get_unchecked_mut for both
arguments causes the borrow created to make the second pointer to invalid the
first.
The pairs of identical MaybeUninit::slice_as_mut_ptr calls similarly
invalidate each other.
There was also a similar borrow invalidation problem with the use of
slice::get_unchecked_mut to derive the pointer for the CopyOnDrop.
link to pref_align_of tracking issue
If we are not going to remove this intrinsic (https://github.com/rust-lang/rust/pull/90877), I think we should at least have a place to centralize discussion around it, so here we go. Intrinsics don't have their own separate features and usually we instead use the public method for tracking it, but this one does not have such a method... so the tracking issue is just a regular link. (And then we sue it for the const part as well.)
update stdarch
2 commits in d219ad63c5075098fc224a57deb4852b9734327d..0716b22e902207efabe46879cbf28d0189ab7924
2021-12-9 23:50:37 +0000 to 2021-12-14 16:17:57 +0100
* Fix a bunch of typos ([Fix a bunch of typos stdarch#1267](https://github.com/rust-lang/stdarch/pull/1267))
* Stabilize armv8 neon instruction set on aarch64 ([Stabilize armv8 neon instruction set on aarch64 stdarch#1266](https://github.com/rust-lang/stdarch/pull/1266))
The update stabilizes armv8 neon instructions on aarch64. #90972
extend `simplify_type`
might cause a slight perf inprovement and imo more accurately represents what types there are.
considering that I was going to use this in #85048 it seems like we might need this in the future anyways 🤷
Constify `bool::then{,_some}`
Note on `~const Drop`: it has no effect when called from runtime functions, when called from const contexts, the trait system ensures that the type can be dropped in const contexts.
Make `TyS::is_suggestable` check for non-suggestable types structually
Not sure if I went overboard checking substs in dyn types, etc. Let me know if I should simplify this function.
Fixes#91832
Remove `in_band_lifetimes` from `rustc_codegen_ssa`
See #91867 for more information.
In `compiler/rustc_codegen_ssa/src/coverageinfo/map.rs`, there are several functions with an explicit `'a` lifetime but only a single `&'a self` parameter. These lifetimes should be redundant given lifetime elision, unless the existential `impl Iterator` has weird issues regarding that. Should the redundant lifetimes be removed?
Removed `in_band_lifetimes` from `library\proc_macro`
Issue [#91867](https://github.com/rust-lang/rust/issues/91867)
This is my first try, I followed the instructions given. Fixed all the errors that were thrown while compiling.
Compiled with stage 0,1, and 2 all of them compiled successfully.
Handle unordered const/ty generics for object lifetime defaults
*feel like I should have a PR description but cant think of what to put here*
r? ```@lcnr```
