docs: clarify pointer provenance of `Rc::as_ptr()`

[y21]

It is unclear whether it is valid to mutate the *const T returned by Rc::as_ptr() without looking at or relying on implementation details (edit: assuming there is no other Rc or Weak to the same T, aka. strong count is 1 and weak count is 0).
A quick look at the function signature in the documentation may suggest that, given it takes a &Rc<T> and returns a *const T, it should be UB to mutate. However, Rc<T> itself does not own the T, so &Rc<T> ≠ &T.
RcBox<T> (private, impl. detail) does own the T, and Rc<T> always contains a mutable pointer to the RcBox, so the type of reference in the receiver (&Rc<T> vs &mut Rc<T>) should be irrelevant as to whether it is valid to mutate the *const T.
I believe it is valid to mutate the *const T as Rc is currently implemented, despite only having a shared reference to Rc<T> and the pointer being const (AFAIK *const vs *mut is just "cosmetic", what matters is how the pointer was obtained)
This relies on implementation details of Rc<T> and I feel like this situation should be documented.

(The same applies to Arc::as_ptr())

use std::rc::Rc;

let foo = Rc::new(1u8);

unsafe {
  // Valid? Relies on implementation details
  let foo_ref = &mut *(Rc::as_ptr(&foo) as *mut u8);
  *foo_ref += 1;
};

println!("{}", foo);

[fee1-dead]

I disagree. Mutating through an Rc's pointer is UB unless its strong_count is 1 and its weak_count is 0.

[y21]

I forgot to add that to the issue, but what I'm after is clarifying whether it's valid to mutate the *const T assuming only one strong reference and no weaks.
As in, Rc::as_ptr() taking &Rc<T> and returning *const T makes it seem like the pointer is read-only even though it's not, but this relies on implementation details.

[RalfJung]

I agree this is a good question.

The current implementation creates a pointer that indeed can be used for mutation if all the other concerns are taken care of (i.e., no other references to this Rc). But the docs don't currently guarantee this.

I think this can be fixed with a doc-only PR, though we'd have to involve the libs-API team for signoff.

[y21]

Reading through this again:

Mutating through an Rc's pointer is UB unless its strong_count is 1 and its weak_count is 0.

Is the weak count actually relevant here? Seems fine to me to have any amount of weak references, given that they first have to be upgraded to an Rc before you can do anything with the T (and upgrading the Weak to an Rc would then violate the strong_count == 1 safety requirement).

[hkBst]

@rustbot labels: +T-opsem +T-libs +A-raw-pointers