Successor to #613's canary redness — a distinct regression, split out so each tracker names one root cause.
What: canary run 32811844428 on nightly-2026-08-25 fails all three platforms with error: enum with no variants (clippy::empty_enums, the renamed pedantic empty_enum, denied via our pedantic = deny). Every failing span points at OUR #[derive(… FromBytes …)] sites (e.g. crates/uffs-mft/src/ntfs/boot_sector.rs:15) — the lint fires on the uninhabited enum zerocopy's derive generates, and derive output carries call-site spans, so external-macro suppression doesn't apply.
Upstream: tracked at google/zerocopy#3414 (open; no fixed release — latest is 0.8.56, which we already pin). Expected fix shapes: zerocopy gating its generated enum with an allow, or clippy adding an is-from-proc-macro guard to the new lint. When a fixed zerocopy ships, the resolution here is a dependency bump (the ethnum pattern).
Not a broken pin: the pinned gate (nightly-2026-08-21) predates the lint; main is unaffected. This blocks the NEXT pin bump only.
Posture (standing rule): empty_enums stays denied — no local #[allow] around the derive sites, no lint-set trimming; this is an upstream false positive, waited out with the lint enabled, exactly like the large_futures ICE before it.
Verification: dispatch nightly-canary.yml after a zerocopy release referencing #3414 (or a clippy-side guard lands in a nightly); close on green.
Successor to #613's canary redness — a distinct regression, split out so each tracker names one root cause.
What: canary run 32811844428 on nightly-2026-08-25 fails all three platforms with
error: enum with no variants(clippy::empty_enums, the renamed pedanticempty_enum, denied via ourpedantic = deny). Every failing span points at OUR#[derive(… FromBytes …)]sites (e.g.crates/uffs-mft/src/ntfs/boot_sector.rs:15) — the lint fires on the uninhabited enum zerocopy's derive generates, and derive output carries call-site spans, so external-macro suppression doesn't apply.Upstream: tracked at google/zerocopy#3414 (open; no fixed release — latest is 0.8.56, which we already pin). Expected fix shapes: zerocopy gating its generated enum with an
allow, or clippy adding an is-from-proc-macro guard to the new lint. When a fixed zerocopy ships, the resolution here is a dependency bump (the ethnum pattern).Not a broken pin: the pinned gate (nightly-2026-08-21) predates the lint;
mainis unaffected. This blocks the NEXT pin bump only.Posture (standing rule):
empty_enumsstays denied — no local#[allow]around the derive sites, no lint-set trimming; this is an upstream false positive, waited out with the lint enabled, exactly like the large_futures ICE before it.Verification: dispatch
nightly-canary.ymlafter a zerocopy release referencing #3414 (or a clippy-side guard lands in a nightly); close on green.