Document that #[derive(IntoBytes)] only supports unsized types which are repr(packed)

[njsmith]

Update (authored by @joshlf)

See #1566 (comment).

This issue tracks improving the documentation on either IntoBytes or the re-export of zerocopy_derive::IntoBytes to document that #[derive(IntoBytes)] does not support unsized types unless those types are also repr(packed).

Original issue text

Original title: Can't #[derive(IntoBytes)] on a slice DST?

I'm experimenting with the current main branch (1ff83c4) and its support for slice DSTs. I wrote:

// This is a dynamically sized type
#[derive(Debug, FromBytes, IntoBytes, KnownLayout, Immutable)]
#[repr(C)]
pub struct StatsReport {
    written: U64,
    values: [U64],
}

As far as I can tell from the docs, this should be supported in this branch?

But it errors out with:

error[E0277]: the size for values of type `[U64<zerocopy::BigEndian>]` cannot be known at compilation time
  --> [...]/stats.rs:21:12
   |
21 | pub struct StatsReport {
   |            ^^^^^^^^^^^ doesn't have a size known at compile-time
   |
   = help: within `StatsReport`, the trait `Sized` is not implemented for `[U64<zerocopy::BigEndian>]`, which is required by `StatsReport: Sized`
note: required because it appears within the type `StatsReport`
  --> [...]/stats.rs:21:12
   |
21 | pub struct StatsReport {
   |            ^^^^^^^^^^^
note: required by a bound in `std::mem::size_of`
  --> /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/mem/mod.rs:312:1

error[E0277]: the size for values of type `[U64<zerocopy::BigEndian>]` cannot be known at compilation time
  --> [...]/stats.rs:23:13
   |
23 |     values: [U64],
   |             ^^^^^ doesn't have a size known at compile-time
   |
   = help: the trait `Sized` is not implemented for `[U64<zerocopy::BigEndian>]`
note: required by a bound in `std::mem::size_of`
  --> /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/mem/mod.rs:312:1

For more information about this error, try `rustc --explain E0277`.

The error message is annoyingly uncommunicative about what's going on, but the problem seems to be the #[derive(IntoBytes)], where cargo expand shows that zerocopy is generating this code:

    unsafe impl ::zerocopy::IntoBytes for StatsReport
    where
        U64: ::zerocopy::IntoBytes,
        [U64]: ::zerocopy::IntoBytes,
        ::zerocopy::macro_util::HasPadding<
            StatsReport,
            {
                ::zerocopy::macro_util::core_reexport::mem::size_of::<StatsReport>()
                    > 0 + ::zerocopy::macro_util::core_reexport::mem::size_of::<U64>()
                        + ::zerocopy::macro_util::core_reexport::mem::size_of::<[U64]>()
            },
        >: ::zerocopy::macro_util::ShouldBe<false>,

which yeah, doesn't seem like that could work.

I figure this might be any of:

• a bug
• not expected to work, docs should be clarified
• chill out dude, this is unreleased and unfinished, we'll get there

...But figured I'd check.

[njsmith]

Further experiment: changing the struct from repr(C) to repr(C, packed) seems to get past this error, even though in this case it doesn't affect the layout.

[joshlf]

This is a limitation in IntoBytes - there's no way for us to determine that all possible instances of an unsized type will be free of padding unless that type is repr(packed). The docs should definitely be improved, though; I'll change this issue to track improving the docs.

See also: #1112

[jswrenn]

@joshlf, given the syntactic absence of repr(packed), could we emit a Self: Unaligned or TrailingField: Unaligned bound to support this case?

[joshlf]

@joshlf, given the syntactic absence of repr(packed), could we emit a Self: Unaligned or TrailingField: Unaligned bound to support this case?

Unfortunately I don't think that works for a few reasons:

• We'd need to be able to determine that a type is unsized. We can't do that syntactically (e.g. the field could be a type alias to a slice type, which we can't observe), and it's not always a property of the type itself (e.g., #[repr(C)] struct Foo<T>(T) is only unsized when T is).
• Self: Unaligned would be sufficient, but TrailingField: Unaligned would not be (e.g. #[repr(C)] struct Bar(u16, [u8]))

Also, there are other cases we'd ideally like to support (like the one mentioned in this issue) where the type has a non-trivial alignment requirement (so Self: Unaligned wouldn't be satisfied), and yet is guaranteed not to have padding; it'd be weird if we supported this use case on piecemeal in a way that would be very opaque and confusing to users.

[joshlf]

Fixed by #1616