🐤 Nightly Canary: upcoming-toolchain regression — c2b4e40

[github-actions]

🐤 Nightly Canary failed on main

Field	Value
Workflow	🐤 Nightly Canary
Run	#1
Attempt	1
Branch	main
Commit	c2b4e40
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: githubrobbi@nios.net

[githubrobbi]

Root-cause analysis (canary working as intended — main is NOT broken)

What tripped: ring 0.17.14's compile-time assertion in src/cpu/arm/darwin.rs fails on the latest floating nightly, macOS/aarch64-apple-darwin leg only:

error[E0080]: evaluation panicked: assertion failed: (CAPS_STATIC & MIN_STATIC_FEATURES) == MIN_STATIC_FEATURES
error[E0080]: evaluation panicked: assertion failed: CAPS_STATIC == MIN_STATIC_FEATURES

ring const-asserts that the compiler's statically-enabled aarch64 target features (CAPS_STATIC) exactly equal its hardcoded baseline (MIN_STATIC_FEATURES). A newer nightly changed the default target-feature set for aarch64-apple-darwin, so CAPS_STATIC no longer matches == and the const eval panics.

Severity: early-warning, not an emergency.

• Our pin (nightly-2026-05-31) builds ring 0.17.14 fine — main CI is green. This only affects future nightlies.
• This is exactly the lead-time the canary exists to provide: do not bump the pin onto an affected nightly until this is resolved.

Dependency reality (a tempting fix that does NOT work): ring is pulled transitively via polars-stream → polars-io "file_cache" → object_store "cloud/http" → ring. polars-stream is our new_streaming feature. cargo tree -i object_store -e features confirms file_cache is hardwired into polars-stream — so we cannot drop object_store/ring by a feature trim without losing new_streaming. Ruled out.

Options (in preference order)

1. Wait + hold the pin (recommended default). No upstream ring fix is published yet (latest is 0.17.14; no web hits for this assertion as of 2026-06-01 — fresh regression). main is unaffected on the current pin. just toolchain-sync's clippy gate (ci(toolchain-sync): gate nightly bump on clippy, drop redundant cargo check #324) + step-back logic already refuses to pin a nightly that fails to compile, so an accidental bump onto an affected nightly is auto-prevented. Action: just don't force a bump; revisit when ring ships a fix.
2. Bump ring when a fixed release lands. ring will almost certainly relax/adjust the darwin assertion (this is a recurring pattern for them on new Apple target-feature defaults). When 0.17.15+ appears, cargo update -p ring --precise <fixed> + a real vet delta audit. This is the eventual clean fix.
3. Upstream nudge. If it lingers, file/track a briansmith/ring issue referencing the new aarch64-apple-darwin default-feature change. (Search found only old/unrelated darwin issues — this is new.)

Recommendation

Leave the pin where it is, keep this issue open as the tracker, and let the canary keep reporting. The toolchain-sync clippy gate already protects us from bumping into the bad window. Close this once ring ships a fix and we've bumped + vetted it.

Refs: briansmith/ring#1063 (darwin compile history), briansmith/ring#1469 (nightly const-eval history).