This allows lints and other diagnostics to refer to items
by a unique ID instead of relying on whacky path
resolution schemes that may break when items are
relocated.
Remove recommendation about idiomatic syntax for Arc::clone
I believe we should not make this recommendation. I don't want to argue that `Arc::clone` is less idiomatic than `arc.clone`, but that the choice is not clear cut and that we should not be making this kind of call in the docs.
The `.clone()` form has advantages too: it is more succinct, it is more likely to be understood by beginners, and it is more uniform with other `clone` calls, indeed with most other method calls.
Whichever approach is better, I think that this discussion belongs in a style guide or textbook, rather than the library docs. We don't talk much about idiomatic code in the docs, this place is pretty exceptional.
The recommendation is also not followed in this repo. It is hard to figure out how many calls there are of the `.clone()` form, but there are 1550 uses of `Arc` and only 65 uses of `Arc::clone`. The recommendation has existed for over two years.
The recommendation was added in https://github.com/rust-lang/rust/pull/42137, as a result of https://github.com/rust-lang/rfcs/pull/1954. However, note that that RFC was closed because it was not necessary to change the docs (the original RFC proposed a new function instead). So I don't think an RFC is necessary here (and I'm not trying to re-litigate the discussion on that RFC (which favoured `Arc::clone` as idiomatic) in any case).
cc @nical (who added the docs in the first place; sorry :-) )
r? @alexcrichton (or someone else on @rust-lang/libs )
Change the placement of two functions.
Right now, the order is as follows:
`pop_front()`
`push_front()`
`push_back()`
`pop_back()`
`swap_remove_back()`
`swap_remove_front()`
I believe it would be more natural, and easier to follow, if we place `pop_back()` right after the `pop_front()`, and `swap_remove_back()` after the `swap_remove_front()` like this:
`pop_front()`
`pop_back()`
`push_front()`
`push_back()`
`swap_remove_front()`
`swap_remove_back()`
The rest of the documentation (at least in this module) adheres to the same logic, where the 'front' function always precedes its 'back' equivalent.
Add APIs for uninitialized Box, Rc, and Arc. (Plus get_mut_unchecked)
Assigning `MaybeUninit::<Foo>::uninit()` to a local variable is usually free, even when `size_of::<Foo>()` is large. However, passing it for example to `Arc::new` [causes at least one copy](https://youtu.be/F1AquroPfcI?t=4116) (from the stack to the newly allocated heap memory) even though there is no meaningful data. It is theoretically possible that a Sufficiently Advanced Compiler could optimize this copy away, but this is [reportedly unlikely to happen soon in LLVM](https://youtu.be/F1AquroPfcI?t=5431).
This PR proposes two sets of features:
* Constructors for containers (`Box`, `Rc`, `Arc`) of `MaybeUninit<T>` or `[MaybeUninit<T>]` that do not initialized the data, and unsafe conversions to the known-initialized types (without `MaybeUninit`). The constructors are guaranteed not to make unnecessary copies.
* On `Rc` and `Arc`, an unsafe `get_mut_unchecked` method that provides `&mut T` access without checking the reference count. `Arc::get_mut` involves multiple atomic operations whose cost can be non-trivial. `Rc::get_mut` is less costly, but we add `Rc::get_mut_unchecked` anyway for symmetry with `Arc`.
These can be useful independently, but they will presumably be typical when the new constructors of `Rc` and `Arc` are used.
An alternative with a safe API would be to introduce `UniqueRc` and `UniqueArc` types that have the same memory layout as `Rc` and `Arc` (and so zero-cost conversion to them) but are guaranteed to have only one reference. But introducing entire new types feels “heavier” than new constructors on existing types, and initialization of `MaybeUninit<T>` typically requires unsafe code anyway.
Summary of new APIs (all unstable in this PR):
```rust
impl<T> Box<T> { pub fn new_uninit() -> Box<MaybeUninit<T>> {…} }
impl<T> Box<MaybeUninit<T>> { pub unsafe fn assume_init(self) -> Box<T> {…} }
impl<T> Box<[T]> { pub fn new_uninit_slice(len: usize) -> Box<[MaybeUninit<T>]> {…} }
impl<T> Box<[MaybeUninit<T>]> { pub unsafe fn assume_init(self) -> Box<[T]> {…} }
impl<T> Rc<T> { pub fn new_uninit() -> Rc<MaybeUninit<T>> {…} }
impl<T> Rc<MaybeUninit<T>> { pub unsafe fn assume_init(self) -> Rc<T> {…} }
impl<T> Rc<[T]> { pub fn new_uninit_slice(len: usize) -> Rc<[MaybeUninit<T>]> {…} }
impl<T> Rc<[MaybeUninit<T>]> { pub unsafe fn assume_init(self) -> Rc<[T]> {…} }
impl<T> Arc<T> { pub fn new_uninit() -> Arc<MaybeUninit<T>> {…} }
impl<T> Arc<MaybeUninit<T>> { pub unsafe fn assume_init(self) -> Arc<T> {…} }
impl<T> Arc<[T]> { pub fn new_uninit_slice(len: usize) -> Arc<[MaybeUninit<T>]> {…} }
impl<T> Arc<[MaybeUninit<T>]> { pub unsafe fn assume_init(self) -> Arc<[T]> {…} }
impl<T: ?Sized> Rc<T> { pub unsafe fn get_mut_unchecked(this: &mut Self) -> &mut T {…} }
impl<T: ?Sized> Arc<T> { pub unsafe fn get_mut_unchecked(this: &mut Self) -> &mut T {…} }
```
… and add a separately-unstable field to force non-exhaustive matching
(`#[non_exhaustive]` is no implemented yet on enum variants)
so that we have the option to later expose the allocator’s error value.
CC https://github.com/rust-lang/wg-allocators/issues/23
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?
Turn `INCOMPLETE_FEATURES` into lint
We do this because it is annoying to see the warning when building rustc and because this is better from a "separation of concerns" POV.
The drawback to this change is that this will respect `--cap-lints`.
Also note that this is not a buffered lint so if there are fatal parser errors then the lint will not trigger.
r? @varkor
Alexander Regueiro