Derive trivial is_bit_valid when possible

[joshlf]

When deriving FromBytes on a type with no generic parameters, the implied TryFromBytes derive's is_bit_valid impl is generated as always returning true. This is faster to codegen, is faster to compile, and is friendlier on the optimizer.

Makes progress on #5

Discussed offline: previous version was unsound; requesting a re-review for the fix

[joshlf]

@jswrenn Take a look at the .stderr files. The extra Self: FromBytes check added in is_bit_valid results in significantly more verbose error messages. It's still obvious what's happening, so it's not a huge deal. I could also see replacing this with one of the following:

• Convince ourselves that there's absolutely no way for compilation to succeed if FromBytes isn't satisfied (risky - what about future language changes a la trivial bounds?)
• In the #[derive(FromBytes)] case, do impl TryFromBytes for Type where Type: FromBytes; maybe this will generate better error messages? Significantly harder to wire through our existing codebase, though
• In all cases of #[derive(Subtrait)], do impl Trait for Type where Type: Subtrait (so that we don't have to special-case this); now all code can more soundly rely on the top-level trait actually being satisfied. Probably still more verbose errors than currently, but maybe not as bad as with the current solution in this PR.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.84%. Comparing base (3aef801) to head (b8eeb75).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1303   +/-   ##
=======================================
  Coverage   87.84%   87.84%           
=======================================
  Files          15       15           
  Lines        5191     5191           
=======================================
  Hits         4560     4560           
  Misses        631      631           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jswrenn]

I expected the expansion for this:

#[derive(FromBytes)]
struct Foo {
    a: u8,
    b: u16,
}

...to look like this:

unsafe impl ::zerocopy::TryFromBytes for Foo
where
    u8: ::zerocopy::FromBytes,
    u16: ::zerocopy::FromBytes,
{
    fn only_derive_is_allowed_to_implement_this_trait() {}
    fn is_bit_valid<A>(candidate: ::zerocopy::Maybe<Self, A>) -> bool
    where
        A: ::zerocopy::pointer::invariant::Aliasing
            + ::zerocopy::pointer::invariant::AtLeast<
                ::zerocopy::pointer::invariant::Shared,
            >,
    {
        true
    }
}

Why doesn't it? Am I missing some subtlety here?

[joshlf]

It's unnecessary. If the top-level trait is FromBytes, then we already know that a trivial is_bit_valid impl is sound because if it wasn't, the FromBytes derive itself would fail. The bound added inside the body of is_bit_valid is just a hedge in case that reasoning has a hole.

I could also see replacing it with impl TryFromBytes for Foo where Foo: FromBytes. However, that has the downside of being non-local in terms of the control flow inside the derive code. The current approach has the advantage that you can reason about the soundness of try_gen_trivial_is_bit_valid entirely by looking at its body.