Skip to content

Pose the function-value adapter fixture through #9911's fixture-closure rustc route: an OPT-IN rustc verdict on the adapter specimen, with its own controls and an honest lane-membership statement - #10064

Closed
gunbai-bot[bot] wants to merge 11 commits into
mainfrom
session/snappy-koi-286

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Auto-opened by session-dashboard for session snappy-koi-286.
Pushing to session/snappy-koi-286 advances this PR.

Worker attestation

Before flipping this PR to ready for review, confirm each item:

  • Title describes the change (not the session id or branch).
  • PR body summarises what and why (replace the TODO below).
  • Tests run: name the command (e.g. npm test, cargo test) and the result.
  • If this closes a work item, the body contains a Closes #N directive.
  • No commits on this branch are surprises (no fork/cherry-pick I did not make).
  • No secrets / credentials / large binaries staged.

Summary

TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.

Test plan

  • TODO: list the commands that ran (or "no tests changed; relied on CI") and the outcome.

gunbc-ci-auto-heal and others added 11 commits September 2, 2026 02:19
…9911's fixture-closure route

#9911 landed a CAPABILITY — a fixture-authorable subject reaching rustc over its
emitted closure. This spends it on a subject that cannot be posed to a text oracle
at all: `v1.compiler.emit_rust` `rust_call_arg_function_value_adapt`, whose claim is
a TRAIT OBLIGATION rather than a spelling.

The pair is minimal-difference: same producer, consumer and call, one authored
difference. The control passes the producer result AS A CALL EXPRESSION (the shape
the adapter keys on); the red binds it to a local first and passes the binding,
which the adapter does not touch. So the only variable across the arms is whether
the adapter fired.

Executed, both directions:
  control  Measured files=6 cargo=Completed status=0
  red      Measured files=6 cargo=Completed status=101
    error[E0277]: expected a `Fn(i64)` closure, found `Rc<dyn Fn(i64) -> i64>`
      --> src/fixture_closure_rustc_function_value_let_probe.rs:22:11
    pair PASSED, test result: ok in 173.84s

The red is a KNOWN HOLE, not a wall working: gunbc accepts it with zero blocking
diagnostics and emits a crate rustc refuses — `gunbc.recurring_failure_mode`
`accepted_source_emits_uncompilable_target` at the function-value seam, committed
as runnable files. When the hole closes the arm flips and is kept as a permanent
regression control (DESIGN §4b(4)).

Lane membership, stated on #9911's own terms: `#[ignore]`d, so ENROLLED AND OPT-IN
via `cargo test --release -p v1-compiler --lib
function_value_adapter_fixture_closure_discrimination -- --ignored`, not executing
by default on push or PR, and `rust-unit-tests` is not a `needs` of the required
aggregate. Candidate evidence, NO WALL: this establishes no rung for the adapter
and discharges no next-rung trigger naming it.

Three new hand-Rust declarations, all enumerated in
`gunbc.emitted_closure_compile_seed_growth` (78 declarations / 78 rows, re-derived);
everything else is reused from the route rather than re-authored.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015XNpHkAWNSqikzKqspogbY
…s-is; regenerated in the next commit)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015XNpHkAWNSqikzKqspogbY
The generated-artifact merge driver left the ours side in the worktree by
design, so the merge commit carried compiler_tests.rs and
v1_compiler_compiler_tests_rust.rs as they stood BEFORE main's
ct_function_value_adapter_bound_alignment_control_test (#9938) landed --
which reads as this PR deleting an executing regression control. It does
not: the bytes here are --required-regen output over the merged .dag
sources, and both blobs are present. DESIGN 4b(4) holds -- the alignment
control stays enrolled and executing on rust-unit-tests, and this PR's
rustc pair is added beside it, not in place of it.

Re-verified on the merged tree: pair PASSED, control status=0, red
status=101 (E0277, attributed), test result: ok in 165.46s.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015XNpHkAWNSqikzKqspogbY
…jection actuator would not run

Two prose corrections in gunbc.emitted_closure_compile_seed_growth, both
about not overclaiming:

- how this pair sits beside #9938's ct_function_value_adapter_bound_alignment
  _control_test: different oracle, different grain, and this #[ignore]d
  consumer does NOT falsify that control's own sentence that no enrolled
  fail-closed rustc consumer covers the adapter on the merge path.
- the projection actuator's refusal is named precisely:                total        used        free      shared  buff/cache   available
Mem:       131166516    54988184    51817236      188464    25778424    76178332
Swap:      260046840     7040528   253006312 on the runner
  reports 7 GiB TOTAL, so the 12 GiB and 30 GiB cgroup caps were larger than
  the machine and MemoryStallRefusedPageThrash is the budget arm working, not
  a limit worth raising.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015XNpHkAWNSqikzKqspogbY
…erated test projections

CI at f0c40bf failed on 'regen FAIL generated surface drift:
gunbc_rust_source_type_bindings.rs' -- main's own drift, fixed on main by
#9998, so the repair here is to integrate main rather than to re-derive that
file on this branch.

The two generated test projections conflicted again (the generated-artifact
merge driver refuses rather than answering). Resolved the same way as before:
take main's bytes and re-apply this lane's --required-regen delta, so the
files differ from main by exactly this PR's additive blob -- compiler_tests.rs
+50/-0, v1_compiler_compiler_tests_rust.rs +6/-1, and
gunbc_rust_source_type_bindings.rs identical to main.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015XNpHkAWNSqikzKqspogbY
…ojections

Integration only: no claim of this lane is changed, extended, or repaired.
Every source-level difference from the lane head 486c9ea is attributable
to a path main also changed over the merge base.

The two stage0 projections that conflicted -- compiler_tests.rs and
v1_compiler_compiler_tests_rust.rs -- were left UNMERGED with no markers by
the generated-artifact driver and were regenerated from the merged authority
rather than resolved by picking a side. Neither regenerated file equals either
stage copy. Regen reached its fixed point: first_generation_equal=true,
planned=150 executed=150 adjudicated=150, declared_divergent=1 [main.rs].

Noted, not acted on: main's src/v1/compiler_tests_rust.dag still declares and
rosters ct_function_value_adapter_bound_alignment_control_test, while main's
emitted compiler_tests.rs carries zero occurrences of the fn it emits. #9886
dropped it from the mirror without touching the roster. The lane head had
already re-derived it, so this merge introduces no new assertion about it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FdxzwWekWhHR2FCTTf8a1b
…y-koi-286

Integration only: no claim of this lane is changed, extended, or repaired.

Corrects an incomplete staging in 1eeeecb. That commit re-derived the
projections correctly but staged only the paths the merge had marked
conflicted, so the regen's third output -- std_realization_schedule.rs,
population_index Nat -> i64 -- was written to the worktree and never
committed, and the tree shipped the pre-regen bytes. A conflict list is not
a census of a regeneration. This merge stages by what the regen names: 192
candidate files compared against the installed mirror, 0 differing.

The authority-vs-mirror question that raised is settled and was never main's:
this regen, #10017's regen, and the emitter all agree on i64. main was
authority-behind on that file at bb96afa and #10017 repaired it.

Regen: first_generation_equal=true, planned=150 executed=150 adjudicated=150,
declared_divergent=1 [main.rs] (not installed).
Fixed point: fixed_point_equal=true referenced_first_generation_equal=true.
Doc projections needed no regeneration -- neither side changed DESIGN.md or
docs/design-ledgers.md over the merge base.

compiler_tests.rs is a clean union: against main it adds exactly this lane's
function_value_adapter_fixture_closure_discrimination; against the lane head
it takes exactly main's three shell-service controls in place of the parked
known-hole probe.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FdxzwWekWhHR2FCTTf8a1b
…future lane

Review 58532 read the deferral as leaving the discovered instance outside
DESIGN 4b's typed authority. The class row is not missing -- #9909 filed
accepted_source_emits_uncompilable_target with two instances and a scope
sentence -- and what this lane found is a THIRD INSTANCE widening it, which
vivid-lark-739 is filing from these receipts in #10020 on a rig that can run
the projection actuator this lane's 7 GiB runner cannot.

So the carrier now names that owner and that PR rather than 'a lane that can
execute the actuator', in the same disposition #10020 uses toward this PR:
citing the open PR rather than asserting paths that do not yet resolve.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014xLgWdoQZSdMjXTTh1WnUm
…t it has one

Review 58546, and it was right: fixture_discrimination_passed asks four
questions -- control compiled, red reached rustc, red did not compile, red
named its own emitted module -- and none of them is about the Fn bound. A
syntax error or any unrelated emission defect in the red fixture's own module
answers all four, so this arm would have gone on passing while the adapter
discrimination it claims to measure had silently stopped existing.

The consumer now adjudicates the red arm's actual diagnostic: error[E0277]
AND Rc<dyn Fn AND let_apply. The three are chosen to pin the SEAM rather than
rustc's prose -- a stable error code for the trait-obligation class, the
function-VALUE rendering, and the consumer whose parameter carries the
impl Fn(..) + Clone bound -- so a rustc release that rephrases its message
cannot quietly turn this into a check of nothing.

The SHARED predicate is deliberately not tightened: it also serves #9911's
text-boundary pair, whose red is a different diagnostic, so baking one
subject's error code into it would fork it or make it false for the other
consumer. Each claim site adjudicates its own expected diagnostic.

Re-run with the assertion in place: control status=0, red status=101 E0277
attributed, pair PASSED, test result: ok in 165.27s. Regen fixed point over
three passes, staged by regen output rather than by conflict list: 192
candidates, 0 differing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014xLgWdoQZSdMjXTTh1WnUm
…e merged authorities

Integration done in the order the driver requires: merge commit, rebuild the
seed FROM the merged tree, regenerate, then commit once -- session branches
are pushed automatically, so an intermediate commit would reach origin and the
drift gate would correctly red on it.

Ran locally, which is where this actuator has to run: gunbc refuses
HostBudgetUnreadable on BuildBuddy (no cgroup limit binds that process) and
the whole-corpus resolve does not fit that runner's 7 GiB anyway. It fits here.

- seed regen to a FIXED POINT over three passes, staged by what the regen
  NAMES rather than by what the merge marked as conflicted: pass 1 installed
  v1_compiler_compiler_tests_rust.rs, pass 2 compiler_tests.rs, pass 3
  installed 0 of 192 with first_generation_equal=true.
- projection gate (generated_artifact_gate main_wet) re-derived DESIGN.md and
  docs/design-ledgers.md; both are now byte-identical to main, which is the
  right answer -- this lane adds no ledger row, and #10020 owns the append.
- compiler_tests.rs against main: +74/-0, which is this lane's #[ignore]d
  consumer plus its new diagnostic adjudication. No removals.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014xLgWdoQZSdMjXTTh1WnUm
…apacity claim this lane has since cleared

INTEGRATION, in the order the driver requires: merge commit, rebuild the seed
FROM the merged tree, regen to a fixed point, gate, then one commit -- pass 1
installed v1_compiler_compiler_tests_rust.rs, pass 2 compiler_tests.rs, pass 3
installed 0 of 192 at first_generation_equal=true, then generated_artifact_gate
main_wet re-derived DESIGN.md and docs/design-ledgers.md.

THE CORRECTION: this carrier said the projection actuator could not run here,
and review 58670 quoted it back as the reason the ledger append is deferred.
That was true of the BuildBuddy runner (7 GiB total, measured) and was never
true of the session container (125 GiB host, 31 GiB cap) -- which is where this
lane just ran it, twice, to integrate main. Capacity no longer defers anything.
What defers the append is OWNERSHIP: #10020 holds the third instance, authored
from this lane's receipts, and projection-touching branches land one at a time.

A receipt that keeps citing a limit the lane has since cleared is the class
this file exists to catch, so the measurement stays recorded against the runner
it belongs to and stops standing in for a reason it no longer supplies.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014xLgWdoQZSdMjXTTh1WnUm
@gunbai-bot

gunbai-bot Bot commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

Closing as already merged, not as abandoned work.

This draft was auto-opened on session/snappy-koi-286 about a minute after #9989 squash-merged as 928dd02. The content it shows is that same content: git diff origin/main...HEAD still reports +391/-3 across 9 files because a SQUASH merge leaves the branch's commits as non-ancestors of main, so the merge-base is the pre-merge point and the three-dot diff re-reports the landed change as if it were pending. The direct git diff origin/main HEAD tells the true story — the branch is now behind main, not ahead of it.

Verified on main rather than inferred from the merge notice:

git ls-tree origin/main fixtures/fixture_closure_rustc/
  function_value_adapter_probe.dag
  function_value_let_probe.dag

Flipping this to ready would spend review budget re-judging merged work and would put a second PR on a branch whose PR already landed.

— sent from snappy-koi-286

@gunbai-bot gunbai-bot Bot closed this Sep 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants