Cast to a DST pointer?

[joshlf]

This question is inspired by the slice_dst crate (cc @CAD97)

Is it valid, given a #[repr(C)] struct with a trailing slice field, to cast a slice fat pointer to a fat pointer to that struct? If so, is it guaranteed that the slice length will be retained as expected? Concretely:

#[repr(C)]
struct Foo {
    bar: u8,
    baz: [u16],
}

fn create_foo_ptr(base: *const u8, elems: usize) -> *const Foo {
    let slice_ptr = std::ptr::slice_from_raw_parts(base as *const u16, elems);
    slice_ptr as *const Foo // <-- Will this produce a `*const Foo` with length `elems` for the `baz` field?
}

[RalfJung]

Oh interesting, I did not realize that we even allow DST raw pointer casts that change the type.

I would strongly assume that this affects only the type, and leaves the value unchanged. But I don't think we fully document what the wide pointer metadata of types like Foo even is?

[joshlf]

Yeah, it'd be great if there were some specified way to construct a DST raw pointer. Speaking for myself, it would allow us to support DSTs in zerocopy.

[RalfJung]

I think the plan is for that to happen via rust-lang/rust#81513

[CAD97]

But I don't think we fully document what the wide pointer metadata of types like Foo even is?

I agree that I don't think it's explicitly documented, but I recall it at least being mentioned in one place that compound DSTs have the same metadata as their tail DST member. I hope it's not just the stdlib source that I recall this from, though...

This is also implicitly reinforced by the error: when you mismatch fat pointer types, you get the error

error[E0606]: casting `*mut (dyn Trait + 'static)` as `*mut [()]` is invalid
  --> src/lib.rs:14:5
   |
14 |     p as *mut _
   |     ^^^^^^^^^^^
   |
   = note: vtable kinds may not match

which (for better or for worse) implies that the fat pointers match when the error is not emitted (i.e. when the DSTs have the same terminal tail DST kind).

The fact that this works is used extensively by the ecosystem at this point, at least by rowan (in rust-analyzer), triomphe, and bitvec.

[joshlf]

I've submitted rust-lang/reference#1417 to document this behavior.

[joshlf]

Just ran across another instance of this being relied upon in the ecosystem.

[RalfJung]

Those are two slice types, that's IMO much less subtle than when structs with slice tail are involved.

[joshlf]

Agreed; my point is just that it's an example of relying on behavior which is technically not guaranteed, but would be with rust-lang/reference#1417.

[joshlf]

Resolved by rust-lang/reference#1417