tree f2a928470eca9ca49926eb634de4dee78d0a2189
parent ced7cc5c6523ff478599ed9188df37e91fd96c68
parent feb775c834361f635df9e3824f9d2ae9582becbb
author bors <bors@rust-lang.org> 1544685139 +0000
committer bors <bors@rust-lang.org> 1544685139 +0000

Auto merge of #56161 - RalfJung:vecdeque-stacked-borrows, r=SimonSapin

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