Outputs in InlineAsm can be read-write, so splitting it out is useful for things like Store-Store folding, as it cannot be done for a Store-AsmOutput.
This PR is intended to make no changes, just be the mechanical split of the enum. Future changes can use the split, like a MIR pass I'm working on and perhaps two-phase borrows.
Move PhantomData<T> from Shared<T> to users of both Shared and #[may_dangle]
After discussing https://github.com/rust-lang/rust/issues/27730#issuecomment-316432083 today with @pnkfelix and @Gankro, we concluded that it’s ok for drop checking not to be much smarter than the current `#[may_dangle]` design which requires an explicit unsafe opt-in.
arbitrary_self_types: add support for raw pointer `self` types
This adds support for raw pointer `self` types, under the `arbitrary_self_types` feature flag. Types like `self: *const Self`, `self: *const Rc<Self>`, `self: Rc<*const Self` are all supported. Object safety checks are updated to allow`self: *const Self` and `self: *mut Self`.
This PR does not add support for `*const self` and `*mut self` syntax. That can be added in a later PR once this code is reviewed and merged.
#44874
r? @arielb1
Move collector to librustc_mir::monomorphize
cc https://github.com/rust-lang/rust/issues/44334 and https://github.com/rust-lang/rust/issues/45276
* I moved the collector to rustc_mir
* I renamed `TransItem` to `MonoItem`. _(I still need to fix up comments and variable names)_
* I got rid of `common.rs` and `monomorphize.rs` from `librustc_trans_utils`. I moved most of the functionality into `TyCtxt`. I realized that the `librustc_trans_utils::common.rs` was just copy pasted from `librustc_trans::common.rs`.
Should I also get rid of the `librustc_trans::common.rs` in this PR? Most of the functionality seems a bit useless, I decided to put some of it into `TyCtxt` but maybe that is not the correct action here.
Should I also get rid of `librustc_trans_utils` completely here? Or should I do it in a separate PR?
Fix the wrong subtraction in align_offset intrinsic.
Given how the stage0 implementation in #43903 is written, as well as that in the RFC, I suppose the current implementation has a typo.
cc #44488, cc @oli-obk.
rustc: ensure optimized enums have a properly aligned size.
Fixes#46769 by padding the optimized enums wrapping packed data as necessary.
Note that this is not the only way to solve this - on nightly, #46436 makes it easier to fix without adding new padding because of the replacement of `packed` flags with a non-redundant scheme.
But because it can't be backported, the optimal fix will be in a separate nightly-only PR (#46809).
