| Age | Commit message (Collapse) | Author | Lines |
|---|
|
fix Box::into_unique effecitvely transmuting to a raw ptr
Miri/Stacked Borrows treat `Box` specially: they assert that it is unique, and tag it appropriately. However, currently, `Box::into_inner` is not aware of that and returns a raw pointer (wrapped in a `Unique`) that carries the same tag as the box, meaning it carries a `Uniq` tag. This leads to all sorts of problems when people use the raw pointer they get out of the `Unique` type.
In the future, it'd be interesting to make `Unique` also carry some kind of uniqueness. In that case, something like this would instead be needed whenever a raw pointer is extracted from a `Unique`. However, that is out-of-scope for the current version of Stacked Borrows. So until then, this changes `into_unique` to perform a proper reference-to-raw-ptr-cast, which clears the tag.
|
|
|
|
This change updates the future and task API as discussed in the stabilization RFC at https://github.com/rust-lang/rfcs/pull/2592.
Changes:
- Replacing UnsafeWake with RawWaker and RawWakerVtable
- Removal of LocalWaker
- Removal of Arc-based Wake trait
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rename `CoerceSized` to `DispatchFromDyn`, and reverse the direction so that, for example, you write
```
impl<T: Unsize<U>, U> DispatchFromDyn<*const U> for *const T {}
```
instead of
```
impl<T: Unsize<U>, U> DispatchFromDyn<*const T> for *const U {}
```
this way the trait is really just a subset of `CoerceUnsized`.
The checks in object_safety.rs are updated for the new trait, and some documentation and method names in there are updated for the new trait name — e.g. `receiver_is_coercible` is now called `receiver_is_dispatchable`. Since the trait now works in the opposite direction, some code had to updated here for that too.
I did not update the error messages for invalid `CoerceSized` (now `DispatchFromDyn`) implementations, except to find/replace `CoerceSized` with `DispatchFromDyn`. Will ask for suggestions in the PR thread.
|
|
This will make receiver types like `Rc<Self>` and `Pin<&mut Self>`
object-safe.
|
|
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/53634.
|
|
|
|
Update to a new pinning API.
~~Blocked on #53843 because of method resolution problems with new pin type.~~
@r? @cramertj
cc @RalfJung @pythonesque anyone interested in #49150
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Replace usages of ptr::offset with ptr::{add,sub}.
Rust provides these helper methods – so let's use them!
|
|
|
|
|
|
|
|
|
|
doc: Clarify the lifetime returned by `Box::leak`
`Box::leak` mentions that it can return a `'static` reference, but it
wasn't immediately clear to me why it doesn't always do so. This is
because of the `T: 'a` constraint needed to form a valid reference, and
in general we want to be more flexible than requiring `T: 'static`.
This patch tries to clarify the relationship between `T` and `'a`.
|
|
|
|
|
|
|
|
`Box::leak` mentions that it can return a `'static` reference, but it
wasn't immediately clear to me why it doesn't always do so. This is
because of the `T: 'a` constraint needed to form a valid reference, and
in general we want to be more flexible than requiring `T: 'static`.
This patch tries to clarify the relationship between `T` and `'a`.
|
|
|
|
|
