Repository navigation
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
Conversation
…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
|
Closing as already merged, not as abandoned work. This draft was auto-opened on Verified on main rather than inferred from the merge notice: 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 |
Auto-opened by session-dashboard for session
snappy-koi-286.Pushing to
session/snappy-koi-286advances this PR.Worker attestation
Before flipping this PR to ready for review, confirm each item:
npm test,cargo test) and the result.Closes #Ndirective.Summary
TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.
Test plan