🐤 Canary: clippy `empty_enums` false positive on zerocopy `FromBytes` derive expansions (nightly ≥ 2026-08-25)

[githubrobbi]

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.

[githubrobbi]

Decision (2026-08-25, operator-confirmed): wait for the upstream fix — no local #[allow], no lint-set change, the canary stays red by design as the pin-bump guard. Re-verification trigger: a zerocopy release referencing google/zerocopy#3414 (then bump the dependency and dispatch nightly-canary.yml), or a clippy-side proc-macro guard reaching a nightly. Close on the first green canary after either.

[githubrobbi]

Root cause refined (2026-08-29) — this is not a clippy regression and not a change to the lint group we can wait out; it is a stabilization side effect.

• clippy::empty_enums has always been guarded on cx.tcx.features().never_type() (its suggestion is "use !"). stabilize never type rust-lang/rust#155499 stabilized never_type on 2026-08-24, so from nightly-2026-08-25 on that guard is true in every crate and the lint fires on every uninhabited enum, #![feature(never_type)] or not.
• The uninhabited enums are zerocopy-derive's own: derive_has_field_struct_union emits one enum ẕ<field> {} per struct field as a type-level field token (zerocopy-derive/src/derive/try_from_bytes.rs), wrapped in the const _: () = { … } block whose #[allow(…)] list (zerocopy-derive/src/util.rs, impl_block wrapper) suppresses non_camel_case_types, non_local_definitions, clippy::missing_inline_in_public_items, … but not clippy::empty_enums. Derive output carries call-site spans, so -D clippy::nursery (the lint now lives in nursery on nightly-2026-08-29; still denied by our posture) lands on our 14 #[derive(FromBytes)] sites.
• Verified on nightly-2026-08-29: -A clippy::nursery silences all 14, -A clippy::pedantic silences none. zerocopy main (checked today) still lacks the allow, so no release will carry a fix until someone lands one.

The upstream fix is one line in zerocopy-derive/src/util.rs: add clippy::empty_enums to that generated #[allow(…)] list (alongside clippy::missing_inline_in_public_items). That keeps the lint enabled for user code while exempting the macro's own field-token enums — the same shape as the existing non_local_definitions entry. Referenced from google/zerocopy#3414.

Posture unchanged: no local #[allow], nursery stays denied. just toolchain-sync steps back to the newest nightly that predates the stabilization (2026-08-24) until a zerocopy release ships the allow; the canary stays red as the pin-bump guard. Closing criterion as before: dependabot bump to the fixed zerocopy → green Monday canary.

[githubrobbi]

Decision 2026-08-29 (operator): document and wait — no local allow, no source patch or fork consumed by this workspace. The toolchain pin stays at nightly-2026-08-21 with the reason recorded in rust-toolchain.toml's resolved-history notes; just toolchain-sync will keep rejecting 08-25+ until a zerocopy release carries the fix for #3414 (a one-line fix is proposed upstream in google/zerocopy#3600). Resolution remains a plain dependency bump (zerocopy → the fixed release), then green canary → close.

[github-actions]

🐤 Nightly Canary failed on main

Field	Value
Workflow	🐤 Nightly Canary
Run	#19
Attempt	1
Branch	main
Commit	e45f13f
Triggered by	@githubrobbi

Filed by ci-failure-notify.yml after the 60-second auto-rerun-transient window: auto-rerun-transient saw no transient signature in the failed-job logs → genuine failure on first attempt.

⚠️ This is an early-warning signal from the floating-nightly canary, not a broken pin. main still builds on the pinned toolchain. Investigate before the next pin bump; if it is an upstream/dep regression, the fix is usually a dependency bump (cf. the ethnum 1.5.2→1.5.3 episode), not a toolchain downgrade.

📧 Notification sent to: cifail@uffs.io

[github-actions]

🐤 Nightly Canary failed on main

Field	Value
Workflow	🐤 Nightly Canary
Run	#20
Attempt	1
Branch	main
Commit	a14d399
Triggered by	@githubrobbi

Filed by ci-failure-notify.yml after the 60-second auto-rerun-transient window: auto-rerun-transient saw no transient signature in the failed-job logs → genuine failure on first attempt.

⚠️ This is an early-warning signal from the floating-nightly canary, not a broken pin. main still builds on the pinned toolchain. Investigate before the next pin bump; if it is an upstream/dep regression, the fix is usually a dependency bump (cf. the ethnum 1.5.2→1.5.3 episode), not a toolchain downgrade.

📧 Notification sent to: cifail@uffs.io