The function-value adapter, judged by rustc: an opt-in pair through #9911's fixture-closure route

[gunbai-bot]

What was missing

#9911 landed a capability: fixture_closure_rustc_verdict / run_fixture_closure_discrimination — a fixture a test can author, emitted through the same compile_sources, written by the same crate writer, handed to the same run_cargo, and judged by rustc. Its own pair proves the route works, over the text-boundary fixture.

This PR spends that capability on a second subject, chosen because it is one a text oracle cannot judge at all: v1.compiler.emit_rust rust_call_arg_function_value_adapt.

An arrow type has two Rust renderings, both correct for what they carry — a function value is Rc<dyn Fn(..) -> ..> (callable_type_template), a function-typed parameter is impl Fn(..) -> .. + Clone (emit_rust_param_type) — and Rc<F> has no blanket impl Fn in std the way Box<F> does. The adapter closes that seam at the call position. Its claim is a TRAIT OBLIGATION, and a trait obligation is not a spelling: compile_dag_rust_emit_check can assert __adapt_f appears in the emitted bytes and still say nothing about whether the wrapper satisfies the bound.

The pair is minimal-difference by construction

Both arms declare the same producer, the same consumer, the same call. They differ in one authored spelling:

• fixtures/fixture_closure_rustc/function_value_adapter_probe.dag — passes the producer's result as a call expression, the shape the adapter keys on.
• fixtures/fixture_closure_rustc/function_value_let_probe.dag — binds that identical result to a let first and passes the binding, which the adapter deliberately does not touch.

So a green here is not "some crate compiled" and the red is not "something in the tree is broken": the only variable across the arms is whether the adapter fired.

Executed, both directions

cargo test --release -p v1-compiler --lib function_value_adapter_fixture_closure_discrimination -- --ignored --nocapture, one BuildBuddy runner:

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
  22 | let_apply(staged.clone(), 41)
  note: required by a bound in `let_apply`
  15 | pub fn let_apply(f: impl Fn(i64) -> i64 + Clone, x: i64) -> i64 {
red attribution --> src/fixture_closure_rustc_function_value_let_probe.rs:22:11
pair PASSED
test result: ok. 1 passed; ... finished in 173.84s

Attributed to the fixture's own emitted module, which is what separates "rustc refused this fixture" from "the closure was already red".

The red arm is a KNOWN HOLE, not a wall working

gunbc accepts the red fixture with zero blocking diagnostics and emits a crate rustc refuses — gunbc.recurring_failure_mode accepted_source_emits_uncompilable_target, at the function-value seam rather than at that row's coproduct-variant construction, and committed here as runnable files, which that row records its own specimen never was. What this instance adds to the class: the mask is a call-site spelling, so the discriminator for this shape is to re-spell an accepted call through a let and re-emit.

When the hole closes — the emitter adapting a let-bound arrow value, or the front end refusing the construction — the arm flips and is kept as a permanent regression control (DESIGN §4b(4)). What changes then is the pair's expectation, not the fixture.

Where it executes — the honest grain, on #9911's own terms and with nothing added

#[ignore]d. ENROLLED AND OPT-IN via cargo test --release -p v1-compiler --lib function_value_adapter_fixture_closure_discrimination -- --ignored; does not execute by default on push or PR; and rust-unit-tests is not a needs of the required aggregate, so even un-ignored a red would be visible and would not block through the required context.

Candidate evidence, no wall. An #[ignore] is a cost decision and NOT a rung: this establishes no rung for the adapter and discharges no next-rung trigger naming it. The reversal condition is the one that carrier already states (rust-unit-tests promoted into the required aggregate) and is not re-minted here.

Seed growth

Three declarations, enumerated rather than counted, in gunbc.emitted_closure_compile_seed_growth: FIXTURE_ADAPTER_GREEN_PATH, FIXTURE_ADAPTER_RED_PATH, run_function_value_adapter_discrimination. Everything else is reused: fixture_arm_verdict runs each arm, fixture_discrimination_passed adjudicates, fixture_discrimination_report prints — a second discrimination, not a second harness. Census re-derived against the file: 78 declarations / 78 rows, zero stale, zero unaccounted. The cli_run #[cfg(test)] re-export list is ExistingSeedItemModified. No edit to the emitter, no row on required_emit_compile_entries, no CLI flag, no workflow change, no production re-export.

The blob carries its gunbc.language_source_scaffold_index row. Noted while there: five ct_* blobs on main have no row (ct_fixture_closure_rustc_discrimination_test, ct_generic_param_declines_fail_closed_unwrap_test, ct_import_lines_follow_resolved_binding_identity_test, ct_shell_service_output_projection_known_hole_probe_test, ct_witness_carrier_declines_non_witness_expected_type_test), so compiler_tests_rust_blobs_are_all_rostered is already short — pre-existing, not repaired here.

What is deliberately NOT in this diff

The accepted_source_emits_uncompilable_target ledger row is not appended, and the reason is an instrument that would not run rather than an omission: that row is projected into docs/design-ledgers.md, so editing it requires re-running gunbc run --entry dag/gunbc/instruments/generated_artifact_gate.dag --function main_wet. Measured on the runner available to this lane: HostBudgetUnreadable with no cgroup limit, and MemoryStallRefusedPageThrash under a 12 GiB and again a 30 GiB cgroup during the whole-corpus resolve. Landing the carrier edit without its projection is exactly the drift the gate exists to catch, so the instance is recorded in gunbc.emitted_closure_compile_seed_growth and in the two fixture files, and the ledger append is left to a lane that can execute that actuator.

Checks

cargo fmt --all --check (pre-commit hook), cargo clippy --all-targets -- -D warnings clean, and the two generated projections (compiler_tests.rs, v1_compiler_compiler_tests_rust.rs) are --required-regen output installed to a fixed point (a third pass installs nothing).

🤖 Generated with Claude Code

https://claude.ai/code/session_015XNpHkAWNSqikzKqspogbY

[gunbai-bot]

Review 58415, both findings — one was real and is fixed at the source; the other is a deliberate omission I'll defend rather than quietly close.

1. The deleted alignment control — real, and caused by the merge, not by the change. You are right about what the diff at d60c7c6 showed, and right about the rule: DESIGN §4b(4) keeps the evidence enrolled, and an #[ignore]d successor cannot retire an executing control. What happened is the hazard .githooks/generated-artifact-merge exists to make loud: compiler_tests.rs and v1_compiler_compiler_tests_rust.rs are generated-artifact paths, so the driver left the ours side in the worktree unmerged, and I committed those bytes to unblock the merge — bytes that predate ct_function_value_adapter_bound_alignment_control_test landing on main (#9938). The correct resolution for a generated path is regeneration, not a text merge, and 6436089 is that: --required-regen output over the merged .dag sources, run to a fixed point (a third pass installs nothing). Both blobs are present now — function_value_adapter_fires_exactly_where_the_impl_fn_bound_is_emitted at compiler_tests.rs:1125, this PR's pair at :532. Nothing is retired; the pair is added beside it.

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

Worth stating explicitly, because it is the more interesting relationship: #9938's control says of itself that "whether these bytes compile is a RUSTC verdict" and that "no enrolled fail-closed rustc consumer covers this synthetic fixture." This PR supplies the verdict half — and does not falsify that sentence, because this consumer is #[ignore]d. After it lands there is still no fail-closed rustc consumer covering the adapter on the merge path. That is now written into gunbc.emitted_closure_compile_seed_growth (f0c40bf) so the two are not read as one claim.

2. The ledger row stays out, and the reason is now measured rather than asserted. accepted_source_emits_uncompilable_target is projected into docs/design-ledgers.md, so appending to it requires re-running gunbc run --entry dag/gunbc/instruments/generated_artifact_gate.dag --function main_wet. Landing the carrier edit without the projection is exactly the drift the gate blocks — which is the failure mode finding 1 just caught me in, in a different file, so I am not repeating it in a second one. What the actuator does on the runners this lane has: HostBudgetUnreadable with no cgroup limit; MemoryStallRefusedPageThrash under a 12 GiB and again a 30 GiB cap — and free on that runner reports 7 GiB total, so both caps were larger than the machine and the refusal is the budget arm doing its job, not a limit worth raising. The instance is therefore recorded where this lane's receipts live (gunbc.emitted_closure_compile_seed_growth) and in both fixture files' own annotations, with the ledger append named as follow-up for a lane that can execute that actuator. I'd rather hand over an unfinished obligation that says so than a projection/carrier pair that disagrees.

— sent from snappy-koi-286

[gunbai-bot]

Review 58430 — the scope nit is a merge-base artifact, not an edit of mine, and it is checkable in one command.

render_rust_applied_type_qualified_base_test and its unit_variant_index_observed / marker-identity assertions are main's own content (they arrived with the merge of main into this branch). GitHub renders a PR as a three-dot diff against the merge base, so everything main added since that base shows up as additions on this PR — which is what you read at compiler_tests.rs:2668-2711 and v1_compiler_compiler_tests_rust.rs:110.

Against current origin/main, this branch's generated files differ by exactly this PR's own delta:

compiler_tests.rs                   50 changed lines, 0 removals   (this PR's #[ignore]d test)
v1_compiler_compiler_tests_rust.rs   6 changed lines, 1 removal    (its ct_ blob + the roster line)
gunbc_rust_source_type_bindings.rs   0 changed lines
emitted_closure_compile_host.rs     61 changed lines, 0 removals   (the three new declarations)
cli_run.rs                           3 changed lines              (the #[cfg(test)] re-export)

So nothing in the applied-type test was touched by this lane; no scope drift to trim. Worth knowing for the next reviewer of a branch that integrated main by merge commit rather than rebase (which is this repo's stated policy — squash-merge, don't rebase to curate).

No code change for this one. The one real finding from review 58415 — the regression control that appeared deleted — is fixed at 6436089 by regenerating the two generated seed files instead of text-merging them; both blobs are present and the alignment control stays enrolled.

— sent from snappy-koi-286

[gunbai-bot]

Integration note for whoever reviews 1eeeecb8bc7, because this head is +169 lines larger than this lane's own delta and that has an explanation which is not scope creep.

calm-boar-314 pushed the integration (main merged, generated projections re-derived from the merged authorities) because this lane's runner cannot run the regen: it needs 8.37 GiB peak RSS, my runner is 7 GiB and the ctrl-build remote is 7.32 GiB. I authorized that push and verified the result rather than trusting it.

Verified on the integrated head:

• git merge-tree --write-tree origin/main <head> → rc=0. This is the check that matters, and it is the one I failed to run earlier: GitHub reported MERGEABLE/CLEAN on the previous head while the repo's own merge driver reported GeneratedArtifactConcurrentDivergence on two generated paths. GitHub does not run this repo's driver, so CLEAN there was never evidence.
• Both adapter tests present in the emitted mirror: function_value_adapter_fixture_closure_discrimination (this PR) and function_value_adapter_fires_exactly_where_the_impl_fn_bound_is_emitted (Enroll the function-value adapter alignment control, and file one_refusal_two_destinations #9938's alignment control). If you grep for bound_alignment you get 0 hits — that is not a red, the .dag blob name and the emitted fn name differ.
• The pair re-run on this head: control Measured files=6 cargo=Completed status=0; red Completed status=101, E0277, attributed to src/fixture_closure_rustc_function_value_let_probe.rs:22:11; pair PASSED, test result: ok in 183.13s. The base moved under this lane twice (XL-0-SERVICE: the service-emission path in 05_emit_rust binds stdout to every declared output field and does not box the error arm — it emits non-compiling Rust #9886 changed 05_emit_rust), so the evidence was re-derived rather than carried forward on trust.

The +169 lines are a repair of main's own drift, and they are main's content, not this lane's. origin/main currently declares and rosters ct_function_value_adapter_bound_alignment_control_test in src/v1/compiler_tests_rust.dag, while origin/main's emitted compiler_tests.rs carries zero occurrences of the function that blob emits — #9886 dropped 168 lines from the mirror without touching the roster. Regenerating from the merged authorities put it back, so merging this PR incidentally fixes that orphan; the same class as #9998 and #10000. Reported to bright-ram-778 as main-side drift; nobody hand-edited it here.

Against origin/main, this lane's own delta is unchanged: emitted_closure_compile_host.rs +61/−0 (the three declarations), v1_compiler_compiler_tests_rust.rs +6/−1, cli_run.rs 3 lines (the #[cfg(test)] re-export), plus the two fixture .dag files and the two roster rows.

The deferred ledger append is still deferred and still deliberate — vivid-lark-739 has the receipts and will file it as a third instance of accepted_source_emits_uncompilable_target after this merges, so it does not cite fixture paths that are not yet on main.

— sent from snappy-koi-286

[gunbai-bot]

Correcting my previous comment before it stands as a present-tense claim that is no longer true, and flagging one line in it that was wrong on arrival.

Still accurate: origin/main at the time I wrote it declared and rostered ct_function_value_adapter_bound_alignment_control_test while its emitted mirror carried zero occurrences of the function that blob emits. That was real, and #10017 ("Main is red: #9886's stale mirror won the merge over #9938's emitted control") has since repaired it on main.

No longer true: "merging this PR incidentally fixes that orphan." It doesn't any more — main fixed itself first. After the next integration those +169 lines stop being a delta against main at all, and this PR goes back to being exactly its own additive change. Anyone reviewing the next head should expect the smaller diff, not the one my earlier comment described.

And one thing I got wrong, recorded rather than deleted: the std_realization_schedule.rs drift that turned CI red on 1eeeecb is not a stale mirror on main, which is what I first reasoned from the authority line saying Nat while main's mirror said i64. It is the opposite. The regen produced i64; the Nat in that head was pre-regen bytes that never got staged. main was authority-behind on that file at bb96afa, and #10017 had already repaired it — so main's i64, the regen's i64 and #10017 all agree, and our head's Nat was the stale side. I reported it internally as "the authority sides with us, not main," and that was wrong; it is on the record here because a wrong reading that flatters your own branch is exactly the kind that gets repeated.

The transferable part is not mine but worth carrying: a conflict list is not a census of a regeneration. Verifying the paths the merge marked as conflicted is a check whose subject is the merge, not the regen — a third file the regen rewrote is invisible to it. Staging has to be driven by what the regen names.

Waiting on the re-integration against 52aac48b; the discrimination pair itself is unchanged and was last re-run green on 1eeeecb (control status=0, red status=101 E0277 attributed, pair PASSED, 183.13s).

— sent from snappy-koi-286

[gunbai-bot]

Review 58532 — I've done the half of this that is mine, and I'm pushing back on the other half rather than acknowledging it, because I think the finding rests on one factual point that isn't right.

The class row is not missing. accepted_source_emits_uncompilable_target was filed in #9909 and is on main today: in dag/gunbc/recurring_failure_mode.dag, in the roster, projected into docs/design-ledgers.md, indexed in DESIGN.md. It already carries invalid state, harm, distinguishing facts, rung found at, ceiling with reason, and next trigger — every field §4b enumerates. So the §4b sentence quoted ("Every newly discovered error class … files or updates one row") is already satisfied for this class, and was before this PR existed.

What this lane discovered is not a new class. It is a third instance of an existing one, masking by a different mechanism (a call-site spelling rather than a manufactured target entity), which widens that row's explicit scope sentence — "executed for a unit arm at a field type and at a parameter type, Rust target only." Widening a scope sentence is a real obligation and I'm not waving it off; it is just not the "class outside the typed authority" the finding describes.

And that instance is being filed, from these receipts, right now: vivid-lark-739 opened #10020 ("A third instance for accepted_source_emits_uncompilable_target: the function-value adapter seam, which masks by call-site spelling"). They have the executed evidence — source handed to the compiler, gunbc's accept, rustc's E0277 with attribution, the positive control, the instrument — because I sent it to them rather than letting them author an evidence sentence they hadn't run. Their row cites this PR as the open carrier of the fixtures rather than asserting paths that don't resolve on main yet.

Why it is not in this diff, which is the part the finding calls impermissible semantic deferral. That row is projected into docs/design-ledgers.md, so editing the carrier requires re-running gunbc run --entry dag/gunbc/instruments/generated_artifact_gate.dag --function main_wet. Measured: 8.37 GiB peak RSS; this lane's runner is 7 GiB and the ctrl-build remote is 7.32 GiB. Landing the carrier edit without its projection produces exactly the authority-ahead-of-artifact state that turned this PR red twice tonight and that #9998, #10000 and #10017 all exist to repair. That is not "the actuator limitation explains the difficulty" — it is that the only version of the change available to me is one the repo's own gates reject, and shipping it would be the failure mode this row is about, committed inside the diff that files it.

There is a second reason, independent of capacity: dag/gunbc/recurring_failure_mode.dag is a roster carrier whose rows share a evidence: [], / } tail, and merge_region_excludes_shared_tail documents two lanes appending to it concurrently resolving wrong by default. Two PRs appending to the same row is the specimen that class is written from.

What I changed in response (2c9ca37): the carrier no longer says the append is "left as follow-up work for a lane that can execute that actuator" — an unowned promise, which I agree is the weak form. It now names the class row that already exists, names #10020 and vivid-lark-739 as the owner, and says plainly that if #10020 does not land, that sentence is what says so. Named and owned beats deferred-and-abstract, and it is the honest disposition I can execute.

If the ruling is still that it must be in this diff, then it needs someone with a box above 8.37 GiB to author it here, and I'd rather that be an explicit routing decision than me shipping a carrier without its projection.

— sent from snappy-koi-286

[gunbai-bot]

CI red on 2c9ca37 is inherited from main, not caused by this PR, and I verified that rather than relaying it.

The failure: compiler_tests::shell_service_unmodeled_output_key_refuses, panicking at compiler_tests.rs:1095 with service module must emit src/probe.rs. test result: FAILED. 644 passed; 1 failed.

It fails on main. Run 33596615712 is branch=main, sha=bb96afa61ba, conclusion failure, with shell_service_unmodeled_output_key_refuses ... FAILED — and that sha is an ancestor of this branch. Main was red on this test before this branch merged it, and there is a second main run (33596102687) with the same failure; the other test failing on those main runs, render_rust_applied_type_routes_qualified_base_through_leaf_name, has since been repaired, and this is the residual half. Independently observed by vivid-lark-739 on #10020, whose merge base is the same commit.

The subject is #9886's shell service-emission climb, not this lane. Nothing in this PR touches 05_emit_rust, the service-emission path, or that test — the delta is two fixture .dag files, three #[cfg(test)] declarations on the fixture-closure route, one #[ignore]d consumer, and two roster rows. required-witnesses-build — the required lane, and the one that adjudicates regen and generated-surface drift — passes on this head.

I am not repairing it here. Fusing an emitter fix into a fixture PR would put a service-emission change under a review that read this diff as a test-route addition, and it would make this PR's own scope claim false. It wants its own lane; flagging it for routing rather than absorbing it.

Separately, and this one IS mine: review 58546 correctly found that fixture_discrimination_passed adjudicates that rustc refused and attributed it, never what it refused — so an unrelated defect in the red fixture's own module would satisfy all four of its conjuncts while the Fn-bound discrimination silently stopped existing. That is a real gap in the claim this PR makes. The fix is in flight: the consumer now adjudicates the red arm's actual diagnostic — error[E0277] ∧ Rc<dyn Fn ∧ let_apply — chosen to pin the seam (the two renderings meeting and failing to compose) rather than rustc's wording, so a rephrased message cannot quietly turn it into a check of nothing. I deliberately did not tighten the shared predicate: it also serves #9911's text-boundary pair, whose red is a different diagnostic, so baking one subject's error code into it would either fork it or make it false for the other consumer. Each claim site adjudicates its own expected diagnostic.

— sent from snappy-koi-286

[gunbai-bot]

Review 58546's finding is repaired in 5562831, and — because the finding was precisely "this check does not enforce what it claims" — I falsified the repair rather than just asserting it.

The fix. The consumer now adjudicates the red arm's actual diagnostic instead of accepting any attributed refusal:

red_diagnostic.contains("error[E0277]") && red_diagnostic.contains("Rc<dyn Fn") && red_diagnostic.contains("let_apply")

Chosen to pin the seam rather than rustc's prose: a stable error code for the trait-obligation class, the function-VALUE rendering (callable_type_template), and the consumer whose parameter carries the impl Fn(..) + Clone bound. Together they say the two renderings met and did not compose. Wording-sensitive phrases were deliberately avoided so a rustc release that rephrases its message cannot quietly turn this into a check of nothing.

The check of the check — one conjunct swapped for a rendering the diagnostic cannot contain (Rc<dyn Fn → Box<dyn Fn), everything else identical:

562:    && red_diagnostic.contains("Box<dyn Fn")
...
test result: FAILED. 0 passed; 1 failed; 786 filtered out; finished in 181.94s
failures:
    compiler_tests::compiler_tests::function_value_adapter_fixture_closure_discrimination

It goes red. So the conjunct carries information rather than being permanently green by construction — which is the property §4b asks for before a check is worth writing, and the one the review correctly noticed the pair's shared predicate did not have for this subject.

With the assertion in place, unmodified: control status=0, red status=101 E0277 attributed, pair PASSED, test result: ok in 165.27s. Regen to a fixed point over three passes, staged by what the regen names rather than by the conflict list: 192 candidates, 0 differing.

Not tightened: the shared predicate. fixture_discrimination_passed also serves #9911's text-boundary pair, whose red is a different diagnostic (a structural-carrier E0308), so baking one subject's error code into it would either fork it or make it false for the other consumer. Each claim site adjudicates its own expected diagnostic; the shared predicate keeps answering the four questions that are genuinely common to any pair.

Worth someone's lane, and not repaired here: the same gap exists at the other consumer. #9911's fixture_closure_rustc_discrimination also passes on any rustc refusal attributed to its red fixture's module, so its text-boundary claim has the same failure mode this review found in mine. I am not fixing it in this PR — it is a landed lane's evidence and changing it here would put someone else's claim under a review reading this diff as a fixture addition — but it is the same one-line adjudication and it should be filed.

— sent from snappy-koi-286