Zeroable derive custom bounds

[zachs18]

Adds the ability to use custom bounds when using derive(Zeroable) instead of the normal "add a bound to each of the generics".

The normal soundness checks are still performed, so the custom bound must guarantee that the struct is actually zeroable, or compilation will fail.

Unresolved questions:

• Should bounds for each field implicitly be added (as described in Allow deriving Zeroable with explicitly provided bounds #190 (comment))? i.e. "Perfect Derive". This wouldn't be hard, and might make the whole "give explicit bounds" part of this PR obsolete (since the "bound on the fields" can be done without additional information), except as to restrict the impl.

Emit bounds for each field

If

#[derive(Zeroable)]
struct Struct<T, U, V> {
  a: Cell<usize>,
  b: PhantomData<T>,
  c: Option<Box<U>>,
  d: [V; 3],
}

emitted

unsafe impl<T, U, V> Zeroable for Struct<T, U, V>
  where
    Cell<usize>: Zeroable,
    PhantomData<T>: Zeroable,
    Option<Box<U>>: Zeroable,
    [V; 3]: Zeroable,
 {}

that would work and not require the user to give any bounds.

Possible future work:

• Something similar for other traits (e.g. Pod for Allow deriving Pod for structs where generics are used only as PhantomData #191. I was looking at it, and it's harder than just re-using this PR's code because of the additional requirements of Pod.)

[wdanilo]

As I replied in the second thread, I believe the bounds generated for each field are a must-have, otherwise this is unsafe with wrongly provided bounds. If the user wants such an unsafe impl, they can always write unsafe impl<...> Zeroable for ..., but deriving should be always safe.

[zachs18]

As stated, the normal soundness checks are still performed, so the derive macro cannot produce unsound code that compiles, as it also emits checks that guarantee that each field is Zeroable. There is a doctest for this in the PR (lines 122-133 of derive/src/lib.rs).

For a concrete example

For a concrete example, this code (under this PR) expands to the following code.

#[derive(bytemuck::Zeroable)]
#[zeroable(bound = "u32: Copy, U: bytemuck::Zeroable")]
struct Asdf<T, U> {
    x: Box<T>,
    y: U,
}

// expands to
struct Asdf<T, U> {
    x: Box<T>,
    y: U,
}
const _: fn() = || {
    #[allow(clippy::missing_const_for_fn)]
    #[doc(hidden)]
    fn check<T, U>()
    where
        u32: Copy,
        U: bytemuck::Zeroable,
    {
        fn assert_impl<T: ::bytemuck::Zeroable>() {}
        assert_impl::<Box<T>>();
    }
};
const _: fn() = || {
    #[allow(clippy::missing_const_for_fn)]
    #[doc(hidden)]
    fn check<T, U>()
    where
        u32: Copy,
        U: bytemuck::Zeroable,
    {
        fn assert_impl<T: ::bytemuck::Zeroable>() {}
        assert_impl::<U>();
    }
};
unsafe impl<T, U> ::bytemuck::Zeroable for Asdf<T, U>
where
    u32: Copy,
    U: bytemuck::Zeroable,
{
}

The fn checks are where the soundness checks are performed, and they will not compile if the fields are not all guaranteed to be Zeroable.

(Also, note to self, unrelated to this PR: the multiple separate const _s could probably be rolled into one.)

[wdanilo]

@zachs18 thanks for the reply and for providing the expansion code, very helpful! What is the reason the expanded code generates the const _: fn() = || { ... } things? I don't think they are needed, unless I'm missing some obvious thing here. The following code is enough and is checking the same things:

unsafe impl<T, U> ::bytemuck::Zeroable for Asdf<T, U>
where
    u32: Copy,
    U: bytemuck::Zeroable {}

[zachs18]

(The failing CI on mips/mips64 is due to rust-lang/rust#113274 )
Okay, I added "perfect derive" semantics to #[zeroable(bound = "...")], i.e. when explicit bounds are given, the given bounds are emitted in addition to a bound for each field's type. (If no explicit bounds are given, the current "bound each type generic" behavior is unchanged).

Marking this PR as ready for review @Lokathor @wdanilo .

[Lokathor]

Looks good to me, I'll wait a while for wdanilo to have a chance to look at it.