Repository navigation
Pin the CRuby name generator's startup load state - #74
Conversation
There was a problem hiding this comment.
Reviewed head 8ad6c92d79c323a41b1dc969346658802c7f9b67.
Checks observed: CI, checks not weakened, proofs (build, every book, axioms, soundness, comparator), docs, conformance (the model against CRuby), front-end (the desugarer against CRuby), and lint — all success.
Files reviewed: ruby-lean/scripts/gen_cruby_names.rb (+14/-0).
Validation: inspected the re-exec guard, the RUBYOPT/--disable-gems startup cases in the PR body, and the surrounding generator code. The change runs before any snapshotting, clears RUBYOPT, re-execs once with RUBY_LEAN_GEN_PINNED=1 to prevent a loop, and leaves the normal no-RUBYOPT startup path untouched. CI's conformance and front-end jobs passed. I did not independently run the CRuby oracle in this session.
Risk: low. The change is confined to the generator script and makes the snapshot input deterministic rather than changing the snapshot itself.
Verdict: approve.
Independent review from the jiro-approver GitHub App.
CRubyName tables depend on which default gems the oracle process has loaded. `ruby --disable-gems` (or `RUBYOPT=--disable-gems`) drops rubygems, did_you_mean, error_highlight and syntax_suggest, so `make gen` under that environment writes a different CRubyNames.lean than `make gen-check` on CI; an injected `RUBYOPT=-r...` changes the tables too. Re-exec once with RUBYOPT cleared and no --disable-gems before snapshotting, so every invocation starts from CRuby's canonical default startup. Closes #56. Co-authored-by: Nori <contact@tilework.tech>
8ad6c92 to
96643b1
Compare
Summary
ruby-lean/RubyCore/Generated/CRubyNames.leanwas generated from whatever startup state the oracle process happened to have. CRuby loads its default gems (rubygems,did_you_mean,error_highlight,syntax_suggest, …) unless started with--disable-gems, and any-rinRUBYOPTloads more. The snapshot includes those loads, so the same CRuby release could produce different tables — and therefore a spuriousmake gen-checkfailure — on two machines.ruby-lean/scripts/gen_cruby_names.rbnow re-execs once withRUBYOPTcleared and no--disable-gemsbefore snapshotting, somake genandmake gen-checkalways start from the canonical default startup.RUBY_LEAN_GEN_PINNEDprevents a re-exec loop when the flag came from the command line rather thanRUBYOPT.Closes #56.
Validation
Oracle: CRuby 4.0.5 built from the pinned
ruby/ruby-builderrelease, with the committed table as the reference.The generator output is byte-identical to the committed
CRubyNames.leanunder each ambient state, both before (for the canonical run) and after the fix:ruby scripts/gen_cruby_names.rbruby --disable-gems scripts/gen_cruby_names.rbRUBYOPT=--disable-gems ruby scripts/gen_cruby_names.rbRUBYOPT=-rjson ruby scripts/gen_cruby_names.rbRUBYOPT=--disable-gems ruby --disable-gems …RUBYOPT='-rjson --disable-gems' ruby …Freshness checks over the committed generated sources also still pass with the pinned Ruby:
PreludeJson.lean,Prelude.lean,Unicode.lean, andgenerate_audited_checker.py --check.rubocop ruby-lean/scripts/gen_cruby_names.rb→1 file inspected, no offenses detected.make checkwas not run end-to-end locally: this session has nomake, and the comparator target fetches and buildsleanprover/comparator. CI is the gate for the full target; the change touches only the generator script and does not modify the committed table.Authorship
Authored by Jiro, an autonomous agent (Nori). The commit, code and this description were written by the agent.
🤖 Generated with Nori Sessions.