`as *mut _` does not cause by-`mut` place evaluation, causing an error stating `DerefMut` is not implemented, but it is

[CAD97]

Given the code:

#![allow(unused_mut)]

use core::mem::ManuallyDrop;

pub struct RefWrapper<'a, T: ?Sized> {
    slot: &'a mut T,
}

impl<'a, T: ?Sized> RefWrapper<'a, T> {
    pub fn into_raw(this: Self) -> *mut T {
        let mut this = ManuallyDrop::new(this);
        // let this = &mut *this;
        this.slot as *mut T
    }
}

The current output is:

error[E0596]: cannot borrow data in a dereference of `ManuallyDrop<RefWrapper<'_, T>>` as mutable
  --> src/lib.rs:13:9
   |
13 |         this.slot as *mut T
   |         ^^^^^^^^^ cannot borrow as mutable
   |
   = help: trait `DerefMut` is required to modify through a dereference, but it is not implemented for `ManuallyDrop<RefWrapper<'_, T>>`

Ideally, this should just work¹. Uncommenting the commented line to add an explicit mutable reborrow allows the code to work as intended. But even if it can't work, the error is clearly very unhelpful, as the issue isn't the lack of DerefMut, but that the compiler selected a shared Deref evaluation of the place.

@rustbot modify labels +C-bug +D-incorrect

Footnotes

1. Importantly, just work and produce a pointer with valid mut provenance. It would be technically correct but misleading to allow &mut T as *mut T behind a shared reference to behave like &mut T as *const T as *mut T. The actually useful behavior is for the fact that as *mut is a by-mut use of the this.slot place to flow back into the selection of whether to evaluate the this.slot place by-ref (via Deref) or by-mut (via DerefMut) the same way other by-mut place usage does. ↩

[estebank]

Triage: no change

[CAD97]

I believe the change implemented in #86647 is the correct fix; namely, considering an as *mut _ use of a place a by-mut usage for the purpose of selecting whether Deref or DerefMut is used in autoborrow evaluation of the place.

For comparison, writing ptr::from_mut(this.slot) (docs instead, compiles as expected.

That PR stalled waiting for lang/compiler confirmation of the change's impact.

Since this does indeed have lang implications,

@rustbot modify labels +T-lang

If we can get team confirmation that #86647 did indeed have the correct approach, I can rebase and resubmit.