Improve IntoBytes padding analysis

[jswrenn]

Many dynamically sized types can be derive(FromBytes) but not derive(IntoBytes) because of shortcomings in our padding analysis. For example:

#[derive(KnownLayout, FromBytes, IntoBytes)]
#[repr(C)]
struct Example {
    header: Header,
    body: [Body],
}

Presently, a user must either mark Example as repr(C, packed), or they must model Example instead as a composite struct containing Refs to the Header and [Body].

Can we make our analysis more sophisticated in this case?

[joshlf]

In theory, the impl of KnownLayout contains enough information to determine whether it's guaranteed that there will never be any padding between any of the fields or after body. However, relying on that would mean adding the assumption that KnownLayout is also derived. For non-repr(C) types, this is fine (since KnownLayout isn't supported for such types, we would know not to even try). For repr(C) types, we would have to choose between either assuming KnownLayout or sticking with the current analysis, which doesn't permit types like this.

Note that even the problem of detecting whether or not a type is unsized is hard - there's no syntactic way to determine whether a concrete type is unsized.