DispatchFromDyn is not implemented for Box, Rc, Arc, or Weak with custom allocators

[matthewpipie]

The DispatchFromDyn trait allows for a type to "be self" such that a trait can become object safe. For example, since Rc<T> is DispatchFromDyn, you can write code like

trait Foo {
    fn foo(self: Rc<Self>);
}

and have a Box<dyn Foo> be valid. This trait is defined in Rc like:

#[unstable(feature = "dispatch_from_dyn", issue = "none")]
impl<T: ?Sized + Unsize<U>, U: ?Sized> DispatchFromDyn<Rc<U>> for Rc<T> {}

However, this implementation does not apply for custom allocators (e.g. Rc<T, A>). This is the same in Arc and in both Rc and Arc's Weak, too. This means that replacing the above trait function with

fn foo(self: Rc<Self, MyAlloc>)

will not compile if you have a Box<dyn Foo>.

Is this an oversight or is this intentional?

[matthewpipie]

Upon further inspection, it seems like Box has some hints to this:

// It is quite crucial that we only allow the `Global` allocator here.
// Handling arbitrary custom allocators (which can affect the `Box` layout heavily!)
// would need a lot of codegen and interpreter adjustments.
#[unstable(feature = "dispatch_from_dyn", issue = "none")]
impl<T: ?Sized + Unsize<U>, U: ?Sized> DispatchFromDyn<Box<U>> for Box<T, Global> {}

I guess then my question is, why does the allocator (specifically the location of the allocated memory) matter to a vtable? Isn't memory just memory?

[the8472]

I guess then my question is, why does the allocator (specifically the location of the allocated memory) matter to a vtable? Isn't memory just memory?

I think because the compiler assumes that box behaves like a primitive pointer and so it can just turn it from a thin into a fat pointer. This this isn't guranteed if the allocator is a non-ZST.

Or at least it expects that the pointer is at offset zero.

// Handling arbitrary custom allocators (which can affect the Box layout heavily!)

I recently special-cased the Box layout. So it's now laid out in field definition order and the pointer at offset zero. But this isn't a lib or lang guarantee, just compiler internals.
rust-lang/rust@df20808

[matthewpipie]

I think because the compiler assumes that box behaves like a primitive pointer and so it can just turn it from a thin into a fat pointer. This this isn't guranteed if the allocator is a non-ZST.

Or at least it expects that the pointer is at offset zero.

Wouldn't this mean that the GlobalAlloc trait could also mess up this assumption? So really, the compiler should be enforcing that the box is using the global allocator and that the global allocator hasn't been overridden?