Repository navigation
type_param_binder_frame_test: emit-twin helpers are translate outputs (Outcome<Node>); resolve on main since #12432 - #12756
Merged
Conversation
…puts (Outcome<Node>); tpb_accepts/tpb_refuses_with are generic over the value #12432 retyped tpb_type_decl_emit_twin/_generic to Outcome<ResolvedTree>, but they return translate_type_expression_project's Outcome<Node>, so the module has not resolved on main since then. The two readers inspect only Accepted/Rejected and the fatal reason, so they take Outcome<T>. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
briansrls
pushed a commit
that referenced
this pull request
Sep 30, 2026
… reversions The local witnesses floor refused where the four claim sets could not: both defects are in modules outside those sets, which is the whole reason the floor exists and is a repeat of a class I have a standing note on (run the consumers, not the file you edited). infer_application_formals was widened by this lane to read a callee's arrow through the callee's facts, and v2.test.claim.declared_parameter_order was never compiled against it. Its two call sites now supply entries: [], which is the fixture's actual premise rather than a stub -- dpo_application puts the Arrow AT positional 0, so infer_operator_arrow answers from the node and the facts route is never consulted. A non-empty list would invent a hypothesis this claim's subject does not have. tpb_type_decl_emit_twin and tpb_type_decl_emit_generic were reverted to Outcome<ResolvedTree> by my hand-composition of main; #12756 had already corrected them to Outcome<Node>, which is what translate_type_expression_project returns. Main's version restored. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
Fixes a latent resolve failure on main:
v2.test.claim.type_param_binder_framehas not resolved since #12432 (339be73).The defect
#12432 retyped
tpb_type_decl_emit_twinandtpb_type_decl_emit_generictoOutcome<ResolvedTree>. Both returnv2.compiler.translatetranslate_type_expression_project(...), which is-> Outcome<Node>. They are translate outputs, not resolve outputs. On main091ea054730,gunbc run --entry src/v2/test/claim/type_param_binder_frame_test.dag --function __no_such_function__refuses with:The fix
Outcome<Node>.tpb_acceptsandtpb_refuses_withinspect only Accepted/Rejected and the fatal reason, so they become generic,Outcome<T>, instead of being duplicated per value type. This follows the precedent ofoutcome_is_accepted<T>inscoped_type_reflection_conformance_test. The resolve claims keep passingOutcome<ResolvedTree>.Verified at 09f1fc6, remotely, with
gunbc run --function: the module resolves (__no_such_function__reaches NoSuchFunction), and these all returntrue:tpb_translator_refuses_a_generic_type_decl_member(the claim over the two retyped producers),tpb_generic_param_binds_to_its_binder, andtpb_undeclared_type_name_still_refuses.Named, not fixed here: why main's floor never caught it
The module's resolve failure is a declared-coverage gap in the floor. In main's latest green merge-queue run, 36653654636 at cf40081 (which already contains #12432),
v2.test.claim.type_param_binder_frameappears inunresolved-module-identities(tpb=1) and not injudged-module-identities(tpb=0). A module that fails to resolve is counted "unresolved" and never becomes a declarations finding, so the run stays green while a test module the floor rosters (thetpb_*rows inv2.workflow.floor_pure_producer_share) does not compile. It surfaced only on the #12628 integration, where changed-witness selection moved it into the judged set and the declarations phase reported the mismatch. That gap (a rostered test module can go unresolved without a finding) belongs to the floor's owners and is out of scope for this PR.🤖 Generated with Claude Code