DispatchFromDyn builtin checks are weaker than CoerceUnsized

[BoxyUwU]

DispatchFromDyn doesn't require the type parameter to only be used in one field and potentially phantomdata, instead it requires one field and arbitarily many ZSTs playground. This in theory means that dispatch from dyn impls can result in effectively arbitrary transmutes from MyZST<dyn Trait> to MyZST<Foo>.

In practice I don't think this is exploitable, regardless I don't think we should stabilize the ability for semi-user-written impls or trait bounds to be written involving this trait until the builtin checks are brought in line with CoerceUnsized.

edit: thanks to @steffahn for pointing this out

＠rfcbot concern DispatchFromDyn builtin checks are weaker than CoerceUnsized

Originally posted by @BoxyUwU in #133820 (comment)

[steffahn]

I think actually @Darksonn noticed this issue.

It's definitely an issue for dispatch-from-dyn as a feature. Is this the right place to track that, or is this specific to the issue only as far as it is relevant for CoercePointee?

[steffahn]

With #![feature(dispatch_from_dyn)], i.e. when a DispatchFromDyn implementation isn't paired with a CoerceUnsized one, this does break the soundness of existing crates such as qcell

#![feature(arbitrary_self_types)]
#![feature(unsize)]
#![feature(dispatch_from_dyn)]

use std::marker::PhantomData;
use std::marker::Unsize;
use std::ops::Deref;
use std::ops::DispatchFromDyn;
use std::ptr;

use qcell::TCell;
use qcell::TCellOwner;

struct Dispatchable<T: ?Sized + 'static> {
    token: TCellOwner<PhantomData<T>>,
    _ptr: *const T,
}

impl<T, U> DispatchFromDyn<Dispatchable<U>> for Dispatchable<T>
where
    T: Unsize<U> + ?Sized,
    U: ?Sized,
{
}

trait Trait<S> {
    fn get_owned(self: Dispatchable<Self>) -> TCellOwner<PhantomData<S>>;
}
impl<S: 'static> Trait<S> for S {
    fn get_owned(self: Dispatchable<Self>) -> TCellOwner<PhantomData<S>> {
        self.token
    }
}

impl<U: ?Sized> Deref for Dispatchable<U> {
    type Target = U;
    fn deref(&self) -> &U {
        panic!()
    }
}

fn owner_from_dyn<S: 'static>(
    x: TCellOwner<PhantomData<dyn Trait<S>>>,
) -> TCellOwner<PhantomData<S>> {
    let s = Dispatchable {
        token: x,
        _ptr: ptr::dangling::<S>(),
    };
    Trait::get_owned(s)
}

fn main() {
    struct S;
    type T = PhantomData<S>;
    type O = TCellOwner<T>;
    let owner1: O = TCellOwner::new();
    let mut owner2: O = owner_from_dyn(TCellOwner::new());
    let c: TCell<T, Option<String>> = TCell::new(Some("Hello World!".into()));
    let r: &str = c.ro(&owner1).as_deref().unwrap();
    *c.rw(&mut owner2) = None;
    println!("{r}");
}

[Darksonn]

Is this really a concern for derive(CoercePointee)? The macro also emits a CoerceUnsize implementation, which comes with the PhantomData validation that is needed to fix this.

[steffahn]

I think it makes sense to track the question of “how much should this be fixed before CoercePointee-stabilization” separately from the issue itself, so I opened #135220

[BoxyUwU]

tbc this issue is supposed to track the bug itself more so than the actual concern for the stabilization PR. I just didn't bother to write out a proper issue description because i was in a hurry :3