iseriser: auto-install pinned Zig toolchain in setup + devcontainer#70
Merged
Conversation
The scaffold generator still emitted the old flat, never-compiled ABI
template: files at `src/interface/abi/{Types,Layout,Foreign}.idr` with a
namespace they didn't match, a `Layout.idr` whose `modNatNZ ... == 0`
proof does not reduce at the type level, no `Proofs.idr`, and no `.ipkg`.
Every newly-generated -iser therefore started with a broken ABI — exactly
the bug a prior session hand-fixed across the family.
Rewrite the Idris2 ABI generators to emit the verified reference pattern,
proven to compile clean under Idris2 0.7.0 (zero warnings, no
believe_me/postulate/holes):
- Nested modules at `src/interface/abi/<Mod>/ABI/{Types,Layout,Foreign,
Proofs}.idr` so each file's path matches its namespace, plus
`src/interface/abi/<iser>-abi.ipkg` (sourcedir=".", lists all four).
- Types: `Result` with a complete `DecEq` (explicit off-diagonals, not
`No absurd`), a non-null `Handle` built via `choose`, and a primitive
enum with a tag-based `Eq` that is warning-free for any arity.
- Layout: real `Divides`/`StructLayout`/`FieldsAligned` machinery and one
concrete, provably C-ABI-compliant context layout.
- Proofs: a non-vacuous `CABICompliant` theorem (each offset pinned by
`DivideBy k Refl`, qualified layout name so it doesn't auto-bind), the
result-code round-trip, and a Nat-level negative control. Verified:
perturbing a field offset makes the proof fail to typecheck.
Tests: assert the generated tree is self-consistent (every ipkg module
present at its namespace path, no leftover template tokens, old flat path
gone) and add an end-to-end test that runs `idris2 --build` on the
generated ABI when the toolchain is present (no-op otherwise, so CI
without idris2 stays green). Update the integration tests for the new
paths and the real proof module.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019xMKB3T4Vo5FYC7Czx3JSH
The Zig FFI bridge is half of the ABI-FFI standard, but nothing installed Zig: `.tool-versions` only lists it (commented), `setup.sh` stops at `just`, and the devcontainer's `postCreateCommand: just deps` referenced a `deps` recipe that did not exist. Unlike the other toolchain pieces, Zig is not distributed via GitHub releases, so it must come from ziglang.org. Add `scripts/install-zig.sh`: an idempotent, fail-soft installer for the pinned Zig 0.14.0 (arch/OS-aware, uses the system CA store the agent proxy populates, never --insecure). If ziglang.org is not on the session's egress allowlist the download 403s and the script exits 0 with an actionable message, so it never blocks setup or a session. Wire it in via the two paths the project already uses: - `setup.sh` gains a "Step 1b: Install Zig toolchain" that runs it. - a new `deps` Justfile recipe (installs Zig, warms Cargo) backs the devcontainer `postCreateCommand: just deps`, which previously errored. Once ziglang.org is allowlisted, future setups and dev containers install Zig automatically with no further change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019xMKB3T4Vo5FYC7Czx3JSH
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
The Zig FFI bridge is half of the ABI-FFI standard, but nothing actually installed Zig:
.tool-versionsonly lists it (commented out),setup.shstops after installingjust,postCreateCommand: just depsreferenced adepsrecipe that didn't exist (so it errored).And unlike the other toolchain pieces, Zig is not distributed via GitHub releases, so it must come from
ziglang.org— which is not on the agent egress allowlist by default (whereasgithub.comis). That's whyzigcouldn't be installed this session.Change
scripts/install-zig.sh— idempotent, fail-soft installer for the pinned Zig 0.14.0: arch/OS-aware, uses the system CA store the agent proxy populates (never--insecure). Ifziglang.orgis not allowlisted the download 403s and the script exits 0 with an actionable message, so it never blocks setup or a session.setup.sh— new "Step 1b: Install Zig toolchain" runs the installer.Justfile— newdepsrecipe (install Zig +cargo fetch) backs the devcontainer'spostCreateCommand: just deps, which previously errored.Once
ziglang.orgis added to the session egress allowlist, future./setup.shruns and dev-container creates install Zig automatically — no further change needed.Verification
sh -n setup.shandsh -n scripts/install-zig.sh— clean.scripts/install-zig.shin-session: it attemptshttps://ziglang.org/download/0.14.0/..., receives the proxy 403, prints the allowlist hint, and exits 0 (fail-soft) — confirming it won't break setup before the allowlist entry is live.This is the reference implementation; the same three-file change is being applied across the other
-iserrepos.🤖 Generated with Claude Code
https://claude.ai/code/session_019xMKB3T4Vo5FYC7Czx3JSH
Generated by Claude Code