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.46%. Comparing base (ea28664) to head (9c82f0c).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1303   +/-   ##
=======================================
  Coverage   87.46%   87.46%           
=======================================
  Files          16       16           
  Lines        6021     6021           
=======================================
  Hits         5266     5266           
  Misses        755      755           

☔ 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.

[joshlf]

Okay, rebasing this on our recent work makes the error messages much less verbose. See the .stderr files in b8eeb75 (old) vs 9c82f0c (new) (unfortunately, diffing these directly is not helpful because of how many changes I rebased on). It's still not perfect, but it's a lot better.

In #1752, we bubble errors up as errors rather than as TokenStreams, and so we can bail earlier and not generate multiple errors in a single derive invocation. I suspect that what happened is that that change is responsible for the errors here becoming much less verbose.

[joshlf]

TODO: Add more output tests for this optimization.