chore: bump the pinned Perry to 0.5.1519, rusqlite to 0.39, and adopt Perry's nightly pin - #16
Conversation
…9, toolchain to Perry's nightly Three changes that only build together: - perry-main.lock: fc6b3378 (0.5.1512) -> 41e8479a5 (0.5.1519), 2026-08-27. - coop-daemon rusqlite 0.37 -> 0.39 (libsqlite3-sys 0.35 -> 0.37). perry-stdlib on this pin links rusqlite 0.39; both bundle sqlite3 and cargo refuses two `links = "sqlite3"` versions in one graph, in either direction. - rust-toolchain.toml pinning nightly-2026-08-20. perry#8550 added the same pin to Perry because perry-runtime now uses float_algebraic. `.perry-main` is excluded from this workspace, so Perry's file never governs a cargo run made from this directory: on stable, coop-daemon and coop-worker fail with E0658 at perry-runtime. Both workflows install the toolchain the file names and fail early if it differs from `.perry-main/rust-toolchain.toml`, so the next bump that moves one pin without the other fails on the assert, not an hour into the proof. Claude-Session: https://claude.ai/code/session_01UZJbhb2FTuakurTHPAKQgd
|
Warning Review limit reachedNext included review available in 51 minutes. View limit detailsLimit details: You’ve used the included review currently available. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (7)
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/settings/billing. Comment |
1 participant
Why now
perry#8546 (two Next.js apps
in_process; the second dispatched one dies with a GC-rootingTypeError) was measured against Perry0.5.1512. The from-space-protect hunt has to continue against currentmain, and #14 already established the pin cannot move without therusqlitebump landing in the same commit — so this is that commit.What changed, and why each piece cannot land alone
perry-main.lock→0.5.1519/41e8479a5(2026-08-27)fc6b3378, including #8528/#8552/#8562, the scanner-latch work #8546 sits on top ofcoop-daemonrusqlite0.37 → 0.39 (libsqlite3-sys0.35 → 0.37)perry-stdlibon this pin linksrusqlite = "0.39"; both bundle sqlite3, and cargo refuses two versions of alinks = "sqlite3"crate in one graph — in either direction (verified in #14)rust-toolchain.tomlpinningnightly-2026-08-20perry-runtimenow usesfloat_algebraic, nightly-only..perry-mainis excluded from this workspace, so Perry's toolchain file never applies to a cargo run made from here — on stable,cargo check --workspacefails with 4× E0658 inperry-runtimeThe toolchain change is the one worth pausing on
Coop was on stable; it now tracks a dated nightly because its path dependency does. The alternative — leave the root on stable and prefix every Perry-dependent cargo invocation (two workflows,
build-perry-libraries.sh, everycargo testin the proof) with+nightly-2026-08-20— spreads the pin across a dozen call sites, and the first one that is missed fails the same way. One file that rustup reads automatically is the smaller surface. Perry's own toolchain-file comment makes the same argument for the same reason.Cost: Coop's toolchain now has to move whenever Perry's does. Both workflows therefore assert the two
rust-toolchain.tomlchannels agree before building, so a bump that moves one pin without the other fails on the assert, not an hour into the Linux proof. Perry's comment says the pin returns to stable oncemin-publish-agestabilises (targeted Rust 1.100, late September); this file follows it back then.fast-check installs from the file (
rustup toolchain installwith no argument); the Linux proof previously installed nothing and used the runner's stable, which would now fail — it installs the pinned toolchain explicitly.Verification
Local, on
nightly-2026-08-20:cargo check --workspace --all-targets— clean (the same command on stable: 4× E0658 inperry-runtime).cargo fmt --all -- --check— clean.cargo clippy -p coop-host-abi -p coop-worker -p coop-cli --all-targets -- -D warnings— clean.cargo test -p coop-host-abi -p coop-cli -p coop-worker --no-fail-fast— all suites pass exceptbinary_http_roundtrip::next_fixture_uses_required_http_abi, which hard-asserts that providers exist undervar/coop/lib/and they are not built on this machine. That is the suite fast-check excludes for exactly this reason; the Linux proof is where it runs against providers built from the new pin.What CI has to prove that I could not locally:
build-perry-libraries.shand the provider identity guard against41e8479a5. LLVM stays at 22 (llvm-sys = "221"on both pins), so no runner change there.Docs: README, quickstart and the providers page's "after bumping the pin" checklist now name the toolchain step.
https://claude.ai/code/session_01UZJbhb2FTuakurTHPAKQgd