Description
openedon Sep 27, 2023
Zerocopy comprises two crates: zerocopy and zerocopy-derive. Zerocopy has a disabled-by-default feature called derive
. When it's enabled, zerocopy depends on zerocopy-derive and re-exports its derives so that users can just depend on zerocopy and don't have to also depend directly on zerocopy-derive.
Some of zerocopy's types implement the same traits that we provide derives for (currently, FromZeroes
, FromBytes
, AsBytes
, and Unaligned
). When the derive
feature is enabled, we use the derives to derive implementations of those traits for our own types. When the derive
feature is disabled, we implement those traits manually.
This creates a potential footgun: How do we know that the impls we emit when derive
is enabled are identical to the impls that we emit when derive
is disabled? Do they have the same bounds?
This issue tracks using the cargo-semver-checks crate to detect such mismatches for us. We already use cargo-semver-checks in CI:
zerocopy/.github/workflows/ci.yml
Lines 207 to 227 in 3bb9a54
Specifically, this issue tracks using cargo-semver-checks to make sure that:
- The
derive
feature is semver backwards-compatible with the absence of thederive
feature - The absence of the
derive
feature is semver backwards-compatible with thederive
feature
Combined, these two conditions should have the effect of ensuring that the APIs with and without derive
are equivalent.
This issue tracks the following concrete tasks:
- Using the technique described in this comment, update
ci.yml
's cargo-semver-checks use to check that:- The crate with the
derive
feature is semver backwards-compatible with the crate without thederive
feature - The crate without the
derive
feature is semver backwards-compatible with the crate with thederive
feature. Note that this case is extra tricky! Thederive
feature re-exports the derives, which means that the APIs are expected to differ! Specifically, we expect that the crate withoutderive
will fail to be backwards-compatible because it has "removed" these exports compared to the crate withderive
. You will need to do one of the following:- Figure out how to tell cargo-semver-checks to expect this difference, and allow it
- Decide that there's no way to support this in cargo-semver-checks, and leave a comment in
ci.yml
explaining why we don't currently support this check
- The crate with the
- Intentionally push two PRs which include this technique and which update zerocopy's source code to violate compatibility:
- One which makes a change which makes
derive
semver-incompatible with no-derive
- One which makes a change which makes no-
derive
semver-incompatible withderive
- One which makes a change which makes