Box::into_unique: do the reborrow-to-raw *after* destroying the Box
Currently we first "reborrow" the box to a raw pointer, and then `forget` it. When tracking raw pointers more strictly (something I am experimenting with locally in Miri), the "use" induced by passing the box to `forget` invalidates the previously created raw pointer.
So adjust my hack from https://github.com/rust-lang/rust/pull/58429 to reorder the two operations.
Ban multi-trait objects via trait aliases
Obviously, multi-trait objects are not normally supported, so they should not be supported via trait aliases.
This has been factored out from the previous PR https://github.com/rust-lang/rust/pull/55994 (see point 1).
r? @Centril
CC @nikomatsakis
------------------
### RELNOTES:
We now allow `dyn Send + fmt::Debug` with equivalent semantics to `dyn fmt::Debug + Send`.
That is, the order of the mentioned traits does not matter wrt. principal/not-principal traits.
This is a small change that might deserve a mention in the blog post because it is a language change but most likely not.
See ce2ee305f9/src/test/ui/traits/wf-trait-object-reverse-order.rs.
// @Centril
Update boxed::Box docs on memory layout
The existing docs for the `Box` type state that "the way `Box` allocates and releases memory is unspecified", and that therefore the only valid pointer to pass to `Box::from_raw` is one obtained from `Box::into_raw`. This is inconsistent with the module-level docs which specify,
> It is valid to convert both ways between a Box and a raw pointer allocated with the Global allocator, given that the Layout used with the allocator is correct for the type. More precisely, a value: *mut T that has been allocated with the Global allocator with Layout::for_value(&*value) may be converted into a box using Box::<T>::from_raw(value). Conversely, the memory backing a value: *mut T obtained from Box::<T>::into_raw may be deallocated using the Global allocator with Layout::for_value(&*value).
This pull request updates the docs for `Box` to make them consistent with the module-level docs and adds some examples of how to use the global allocator in conjunction with `Box::from_raw` and `Box::into_raw`.
Document BinaryHeap time complexity
I went into some detail on the time complexity of `push` because it is relevant for using BinaryHeap efficiently -- specifically that you should avoid pushing many elements in ascending order when possible.
r? @Amanieu
Closes#47976. Closes#59698.
Fix intra-doc link resolution failure on re-exporting libstd
Currently, re-exporting libstd items as below will [occur a lot of failures](https://gist.github.com/taiki-e/e33e0e8631ef47f65a74a3b69f456366).
```rust
pub use std::*;
```
Until the underlying issue (#56922) fixed, we can fix that so they don't propagate to downstream crates.
Related: https://github.com/rust-lang/rust/pull/56941 (That PR fixed failures that occur when re-exporting from libcore to libstd.)
r? @QuietMisdreavus
I went into some detail on the time complexity of `push` because it is
relevant for using BinaryHeap efficiently -- specifically that you
should avoid pushing many elements in ascending order when possible.
Use iter() for iterating arrays by slice
These `into_iter()` calls will change from iterating references to
values if we ever get `IntoIterator` for arrays, which may break the
code using that iterator. Calling `iter()` is future proof.
These `into_iter()` calls will change from iterating references to
values if we ever get `IntoIterator` for arrays, which may break the
code using that iterator. Calling `iter()` is future proof.
This updates to 0.1.13 for `compiler_builtins`, published to fix a few
issues. The feature changes here are updated because `compiler_builtins`
no longer enables the `c` feature by default but we want to do so
through our build still.
Closes#60747Closes#60782
string: implement From<&String> for String
Allow Strings to be created from borrowed Strings. This is mostly
to make things like passing `&String` to an `impl Into<String>`
parameter frictionless.
Fixes#59827.
Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators
Provided a `DoubleEndedIterator` has finite length, `Iterator::last` is equivalent to `DoubleEndedIterator::next_back`. But searching forwards through the iterator when it's unnecessary is obviously not good for performance. I ran into this on one of the collection iterators.
I tried adding appropriate overloads for a bunch of the iterator adapters like filter, map, etc, but I ran into a lot of type inference failures after doing so.
The other interesting case is what to do with `Repeat`. Do we consider it part of the contract that `Iterator::last` will loop forever on it? The docs do say that the iterator will be evaluated until it returns None. This is also relevant for the adapters, it's trivially easy to observe whether a `Map` adapter invoked its closure a zillion times or just once for the last element.
Document the order of {Vec,VecDeque,String}::retain
It's natural for `retain` to work in order from beginning to end, but
this wasn't actually documented to be the case. If we actually promise
this, then the caller can do useful things like track the index of each
element being tested, as [discussed in the forum][1]. This is now
documented for `Vec`, `VecDeque`, and `String`.
[1]: https://users.rust-lang.org/t/vec-retain-by-index/27697
`HashMap` and `HashSet` also have `retain`, and the `hashbrown`
implementation does happen to use a plain `iter()` order too, but it's
not certain that this should always be the case for these types.
r? @scottmcm
It's natural for `retain` to work in order from beginning to end, but
this wasn't actually documented to be the case. If we actually promise
this, then the caller can do useful things like track the index of each
element being tested, as [discussed in the forum][1]. This is now
documented for `Vec`, `VecDeque`, and `String`.
[1]: https://users.rust-lang.org/t/vec-retain-by-index/27697
`HashMap` and `HashSet` also have `retain`, and the `hashbrown`
implementation does happen to use a plain `iter()` order too, but it's
not certain that this should always be the case for these types.
fix LinkedList invalidating mutable references
The test `test_insert_prev` failed in Miri due to what I consider a bug in `LinkedList`: in various places, `NonNull::as_mut` got called to modify the `prev`/`next` pointers of existing nodes. In particular, the unstable `insert_next` has to modify the `next` pointer of the node that was last handed out by the iterator; to this end it creates a mutable reference to the *entire node* that overlaps with the mutable reference to the node's content that was handed out by the iterator! Thus, the next use if said mutable reference is UB.
In code:
```rust
loop {
match it.next() { // mutable reference handed to us
None => break,
Some(elt) => {
it.insert_next(*elt + 1); // this invalidates `elt` because it creates an overlapping mutable reference
match it.peek_next() {
Some(x) => assert_eq!(*x, *elt + 2), // this use of `elt` now is a use of an invalid pointer
None => assert_eq!(8, *elt),
}
}
}
}
```
This PR fixes that by using `as_ptr` instead of `as_mut`. This avoids invalidating the mutable reference that was handed to the user. I did this in all methods called by iterators, just to be sure.
Cc @Gankro
make liballoc internal test suite mostly pass in Miri
I discovered, to my surprise, that liballoc has two test suites: `liballoc/tests`, and a bunch of stuff embedded directly within liballoc. The latter was not covered by [miri-test-libstd](https://github.com/RalfJung/miri-test-libstd) yet. This disables in Miri the tests that Miri cannot support or runs too slowly.
