This reverts commit 7f1d1c6d9a.
The original commit was created because mdBook and rustdoc had
different generation algorithms for header links; now with
https://github.com/rust-lang/rust/pull/39966 , the algorithms
are the same. So let's undo this change.
... when I came across this problem, I said "eh, this isn't fun,
but it doesn't take that long." I probably should have just actually
taken the time to fix upstream, given that they were amenable. Oh
well!
Add `{into,from}_raw` to Rc and Arc
These methods convert to and from a `*const T` for `Rc` and `Arc` similar to the way they work on `Box`. The only slight complication is that `from_raw` needs to offset the pointer back to find the beginning of the `RcBox`/`ArcInner`.
I felt this is a fairly small addition, filling in a gap (when compared to `Box`) so it wouldn't need an RFC. The motivation is primarily for FFI.
(I'll create an issue and update a PR with the issue number if reviewers agree with the change in principle **Edit: done #37197**)
~~Edit: This was initially `{into,from}_raw` but concerns were raised about the possible footgun if mixed with the methods of the same name of `Box`.~~
Edit: This was went from `{into,from}_raw` to `{into,from}_inner_raw` then back to `{into,from}_raw` during review.
The original description suggests that the original `Rc<T>` itself is downgraded, which doesn't seem to be what the code does. At the same time, `Rc` is one of those types that can do weird things with only a shared reference, so I thought it would be good to be clear.
This allows printing pointers to unsized types with the {:p} formatting
directive. The following impls are extended to unsized types:
- impl<'a, T: ?Sized> Pointer for &'a T
- impl<'a, T: ?Sized> Pointer for &'a mut T
- impl<T: ?Sized> Pointer for *const T
- impl<T: ?Sized> Pointer for *mut T
- impl<T: ?Sized> fmt::Pointer for Box<T>
- impl<T: ?Sized> fmt::Pointer for Rc<T>
- impl<T: ?Sized> fmt::Pointer for Arc<T>
This hairy conditional doesn't need to be so. It _does_ need to be a
thin pointer, otherwise, it will fail to compile, so let's pull that out
into a temporary for future readers of the source.
/cc @nrc @SimonSapin @Gankro @durka , who brought this up on IRC
This hairy conditional doesn't need to be so. It _does_ need to be a
thin pointer, otherwise, it will fail to compile, so let's pull that out
into a temporary for future readers of the source.
Also, after a discussion with @pnkfelix and @gankro, we don't need these
null checks anymore, as zero-on-drop has been gone for a while now.
This is a standard "clean out libstd" commit which removes all 1.5-and-before
deprecated functionality as it's now all been deprecated for at least one entire
cycle.
Sometimes when writing generic code you want to abstract over
owning/pointer type so that calling code isn't restricted by one
concrete owning/pointer type. This commit makes possible such code:
```rust
fn i_will_work_with_arc<T: Into<Arc<MyTy>>>(t: T) {
let the_arc = t.into();
// Do something
}
i_will_work_with_arc(MyTy::new());
i_will_work_with_arc(Box::new(MyTy::new()));
let arc_that_i_already_have = Arc::new(MyTy::new());
i_will_work_with_arc(arc_that_i_already_have);
```
Please note that this patch doesn't work with DSTs.
Also to mention, I made those impls stable, and I don't know whether they should be actually stable from the beginning. Please tell me if this should be feature-gated.
