Kill remaining uses of mem::uninitialized in libcore, liballoc
Kill remaining uses of mem::uninitialized in libcore and liballoc, and enable a lint that will warn when uses are added again in the future.
To avoid casting raw pointers around (which is always very dangerous because it is not typechecked at all -- it doesn't even get the "same size" sanity check that `transmute` gets), I also added two new functions to `MaybeUninit`:
```rust
/// Get a pointer to the first contained values.
pub fn first_ptr(this: &[MaybeUninit<T>]) -> *const T {
this as *const [MaybeUninit<T>] as *const T
}
/// Get a mutable pointer to the first contained values.
pub fn first_mut_ptr(this: &mut [MaybeUninit<T>]) -> *mut T {
this as *mut [MaybeUninit<T>] as *mut T
}
```
I changed some of the existing code to use array-of-`MaybeUninit` instead of `MaybeUninit`-of-array, successfully removing raw pointer casts there as well.
Improve Box<T> -> Pin<Box<T>> conversion
I found the `From` trait conversion for this very hard to find, having a named function for it is much more discoverable. Also fixes#56256 as I need that in the place I'm using this.
Has a placeholder tracking issue, will file an issue once I get feedback.
box: Add documentation for `From` impls
This is a part of #51430. A brief description of the behaviour and examples are added to the documentation.
I am not sure what sort of examples to put for the `From` for `Pin` as my [code](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=97c908f44e41c9faeffec5b61d72a03e) doesn't even manage to compile using the nightly build.
Somehow I feel that I missed out something so do let me know if more information is needed in the documentation or any of the examples require change.
Pin stabilization
This implements the changes suggested in https://github.com/rust-lang/rust/issues/55766#issue-378417538 and stabilizes the `pin` feature. @alexcrichton also listed several "blockers" in that issue, but then in [this comment](https://github.com/rust-lang/rust/issues/55766#issuecomment-445074980) mentioned that they're more "TODO items":
> In that vein I think it's fine for a stabilization PR to be posted at any time now with FCP lapsed for a week or so now. The final points about self/pin/pinned can be briefly discussed there (if even necessary, they could be left as the proposal above).
Let's settle these last bits here and get this thing stabilized! :)
r? @alexcrichton
cc @withoutboats
deny intra-doc link resolution failures in libstd
Fixes#56693.
Until we land a fix for the underlying issue (#56922), we can at least fix the failures in libstd so they don't propagate to downstream crates.
Add unstable VecDeque::rotate_{left|right}
Like the ones on slices, but more efficient because vecdeque is a circular buffer.
Issue that proposed this: https://github.com/rust-lang/rust/issues/56686
~~💣 Please someone look very carefully at the `unsafe` in this! The `wrap_copy` seems to be exactly what this method needs, and the `len` passed to it is never more than half the length of the deque, but I haven't managed to prove to myself that it's correct 💣~~ I think I proved that this code meets the requirement of the unsafe code it's calling; please double-check, of course.
This lets you write methods using `self: Rc<Self>`, `self: Arc<Self>`, `self: Pin<&mut Self>`, `self: Pin<Box<Self>`, and other combinations involving `Pin` and another stdlib receiver type, without needing the `arbitrary_self_types`. Other user-created receiver types can be used, but they still require the feature flag to use.
This is implemented by introducing a new trait, `Receiver`, which the method receiver's type must implement if the `arbitrary_self_types` feature is not enabled. To keep composed receiver types such as `&Arc<Self>` unstable, the receiver type is also required to implement `Deref<Target=Self>` when the feature flag is not enabled.
This lets you use `self: Rc<Self>` and `self: Arc<Self>` in stable Rust, which was not allowed previously. It was agreed that they would be stabilized in #55786. `self: Pin<&Self>` and other pinned receiver types do not require the `arbitrary_self_types` feature, but they cannot be used on stable because `Pin` still requires the `pin` feature.
Short-circuit Rc/Arc equality checking on equal pointers where T: Eq
based on #42965
Is the use of the private trait ok this way? Is there anything else needed for this to get pulled?
Document time of back operations of a Linked List
Popping and pushing from the end of a linked list is constant time. This
documentation is already there for popping and pushing from the front.
@bors: r+ 38fe8d2 rollup
Fix BTreeMap UB
BTreeMap currently causes UB by created a shared reference to a too-small allocation. This PR fixes that by introducing a `NodeHeader` type and using that until we really need access to the key/value arrays. Avoiding run-time checks in `into_key_slice` was somewhat tricky, see the comments embedded in the code.
I also adjusted `as_leaf_mut` to return a raw pointer, because creating a mutable reference asserts that there are no aliases to the pointee, but that's not always correct: We use `as_leaf_mut` twice to create two mutable slices for keys and values; the second call overlaps with the first slice and hence is not a unique pointer.
Fixes https://github.com/rust-lang/rust/issues/54957
Cc @nikomatsakis @Gankro
Test capacity of ZST vector
Initially, #50233 accidentally changed the capacity of empty ZST. This was pointed out during code review. This commit adds a test to prevent capacity of ZST vectors from accidentally changing to prevent that from happening again.
This was an accidental regression from #56092, but for `no_std` targets
being built and distributed we want to be sure to activate the
compiler-builtins `mem` feature which demangles important memory-related
intrinsics.
VecDeque: fix for stacked borrows
`VecDeque` violates a version of stacked borrows where creating a shared reference is not enough to make a location *mutably accessible* from raw pointers (and I think that is the version we want). There are two problems:
* Creating a `NonNull<T>` from `&mut T` goes through `&T` (inferred for a `_`), then `*const T`, then `NonNull<T>`. That means in this stricter version of Stacked Borrows, we cannot actually write to such a `NonNull` because it was created from a shared reference! This PR fixes that by going from `&mut T` to `*mut T` to `*const T`.
* `VecDeque::drain` creates the `Drain` struct by *first* creating a `NonNull` from `self` (which is an `&mut VecDeque`), and *then* calling `self.buffer_as_mut_slice()`. The latter reborrows `self`, asserting that `self` is currently the unique pointer to access this `VecDeque`, and hence invalidating the `NonNull` that was created earlier. This PR fixes that by instead using `self.buffer_as_slice()`, which only performs read accesses and creates only shared references, meaning the raw pointer (`NonNull`) remains valid.
It is possible that other methods on `VecDeque` do something similar, miri's test coverage of `VecDeque` is sparse to say the least.
Cc @nikomatsakis @Gankro
* Update bootstrap compiler
* Update version to 1.33.0
* Remove some `#[cfg(stage0)]` annotations
Actually updating the version number is blocked on updating Cargo
