Repository navigation
reference_derived_use_lines' export-proof wall fails by SILENT OMISSION, so a module's emitted REEXPORTS vary with its closure and nothing counts it: land the typed refusal the note's own 'step-2 is future work' names - #9579
Closed
gunbai-bot[bot] wants to merge 26 commits into
Closed
gunbai-bot[bot] wants to merge 26 commits into
gunbai-bot[bot] wants to merge 26 commits into
Conversation
…lit variant delegation out of registry-absent REBUILT ON MAIN'S CONSTRUCTION. gunbc#9439 landed the per-candidate disposition twelve hours ago -- CandidateSurvived / CandidateOwnModule / CandidateRegistryAbsent / CandidateExportProofFailed, with a census and a row at (module, name, disposition) grain. My branch carried an independently written classifier with the same four arms; it is DELETED rather than merged, because two authorities for one decision is the section 3 violation and theirs is on main. WHAT #9439 DID NOT DO, by its own note: the census 'is NOT SURFACED during an ordinary build'. So the two FAILING arms still vanished from the emission -- no diagnostic, no location, nothing a build reports. That is the empty-observation narrow: the emitter answers 'this name is not part of the interface' where the truth is 'I could not prove that it was', and DESIGN rates a narrow strictly worse than the widen section 5 forbids, because a widen is merely expensive and a narrow is silently uncovered. reference_derived_row_diagnostics is a THIRD projection of rows that already exist, beside the use-lines and the census. Nothing re-derives the disposition, so the emitted crate cannot move. TWO diagnostics, not one carrying a cause (ruling: warm-hawk-909 via smart-ram-730). Registry-absent is fixed by AUTHORING AN IMPORT; export-proof-failed is fixed by making the emitter able to prove an export the provider already holds. Opposite remedies, different owners, different populations, potentially different reachability. DESIGN 4b files one row per class. THE FIFTH ARM, and it exists because it was MEASURED. A census of the failing arms over the regen seed closure returned a population dominated by bare VARIANT names -- Absent, Cons, Eq, ExprCall, Bind -- all landing in CandidateRegistryAbsent, because the registry holds declarations and a variant is not one. #9439 filters candidates by `already` and is_kernel_type only, with no variant filter ahead of the disposition, so its registry-absent column counts mostly names already correctly bound. THE ARM CARRIES ITS PARENT, and that is the design rather than a detail. The tempting shape -- one arm meaning 'variants need no import' -- is FALSE and reproduces the same conflation one level down: a variant whose parent is declared here is bound by the module's own use-glob and owes nothing, while a variant whose parent lives elsewhere needs that PARENT imported. Opposite remedies. So the arm claims the obligation is DELEGATED and names the delegate; the parent then answers for itself as its own candidate row. Objection raised by smart-ram-730, who was right that my first shape repeated the defect it was fixing. NOT ESTABLISHED, and said so on the carrier rather than assumed: delegation is sound only if every parent named by a routed row is itself a candidate. That check is mechanical and is the arm's next rung. Witness: #9439's census witness extended -- the fifth arm's discriminating RED (red against the four-arm classifier, green against five), a positive control that a non-variant still answers registry-absent, and three tests over the diagnostics (only the two failing arms produce any, both advisory, opposite remedies in the text). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…nd the TypeSummary import path Both caught by execution rather than review: the emitter refused with 2 hard diagnostics before writing any candidate tree. - emit_module_full built a ModuleEmission without import_refusals after the type gained the field. - the census witness imported TypeSummary/EnumRepr from v1.compiler.emit_info, which is not the module's declared name; it is v1.compiler.infer_emit_info. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…able The seed mirror is a TWO-FILE change for a new 00_core coproduct variant -- declaration in v1_std_core.rs, exhaustive match arms in cli_run.rs -- and the two are circularly ordered: the arms name variants the committed mirror does not carry, so generation 0 stops building the moment they land alone. rustc reports E0004 against the CONSUMING file, which points away from the missing half. Mirrors regenerated by generation 0 from the edited .dag; three files drifted, including the emitted census witness. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…t population is target-language tokens THE CENSUS RAN, on the rebuilt construction, over the regen seed closure (claim_executor --required-regen --source-root dag --source-root src/v2, whose subject is regen_input_sources grown to a joint fixpoint over import, dotted-reference and bare-reference edges). Two arms instrumented, generation 1: export-proof-failed 0 registry-absent 473 rows, 63 distinct names, 110 modules AND READING THE 473 DECIDED THE DESIGN. The top of that population is Vec 88, bool 73, Option 50, i64 48, empty_map 33, then BTreeSet, Fn, fn, u8, serde_json, '_' and '-'. Those are RUST TARGET-LANGUAGE tokens, proposed by the candidate walk's emitted-source arm, which tokenizes the module's own emitted Rust and offers every identifier in it. No .dag provider can ever supply 'bool'. Registry-absent is therefore the CORRECT disposition for them and a diagnostic would be a false report in nearly every row -- printed on every build, in every module, forever. So that arm stays a census column. Its trigger is not a burndown of the 473: it is that the candidate walk stop proposing target-language vocabulary, after which the diagnostic can be wired with no other change. ReferenceDerivedImportProviderUnknown stays DECLARED and is produced by nothing. The class is real and its shape is settled; only its input is not yet clean. THE FLIP CONDITION IS NOW MET FOR ExportUnproven, both halves: population zero over a named closure, AND a discriminating RED authorable -- and authored -- at the fixture boundary, which is what separates 'observed zero' from 'cannot fire'. Whether it flips is warm-hawk-909's call. A REFUTED PREDICTION, recorded because it was decision-relevant and was asked for before either arm flips: registry-absent was expected to overlap heavily with UnlistedImportUse, both being described as 'referenced but never imported'. Measured on one run -- 63 registry-absent names, 36 UnlistedImportUse names, INTERSECTION ZERO. UnlistedImportUse names .dag types masked at resolve time; registry-absent is dominated by Rust tokens that never reached the resolver. They are not two views of one population, so ProviderUnknown's trigger does NOT point at the family-closure-SVN burndown as this carrier previously assumed. Witness gains registry_absent_produces_no_diagnostic, which fails the moment someone wires that arm -- the wall that keeps the false reports out. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ion met warm-hawk-909 approved the flip: population zero over a named closure AND a discriminating RED authorable -- and authored -- at the fixture boundary. The second half is what separates a real wall that is quiet from an arm that has never fired, and only the first is a count. ReferenceDerivedImportExportUnproven leaves the advisory arms of is_error_diagnostic, is_interpreter_blocking_diagnostic and the discovery-corpus advisory set; the default blocking arm now carries it. ProviderUnknown stays advisory and stays produced by nothing. The emission still produces its files beside a blocking diagnostic rather than returning none: production precedes adjudication, so the candidate tree survives the refusal and the refusal is what stops the line. The carrier now records why ProviderUnknown must stay unwired in the strongest available form, which is not that its rows are unfixable: Vec/bool/Option/i64 are EVIDENCE THE CANDIDATE FILTER IS WRONG, and wiring a permanently-false report onto nearly every build is worse than shipping nothing because IT TRAINS READERS TO IGNORE THE CHANNEL. A diagnostic nobody reads is worth less than an absent one, because the absent one is honest about its coverage. Witness updated: the export-unproven diagnostic is asserted blocking rather than advisory. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ard-free TWO FIXES, both from clever-boar-140, who owns the coproduct. 1. MECHANISM ATTRIBUTION WAS WRONG IN MY CARRIER. I wrote that the candidate filter's emitted-source disjunct 'offers any identifier appearing in the emitted Rust'. It cannot: that disjunct is an admission GATE over an already proposed candidate list. The PRODUCER of Vec/bool/i64 is collect_item_realized_surface_names -- rust_identifier_tokens over render_rust_type -- which emits target-language SPELLINGS by construction, and reference_is_host_realized_builtin misses them because it is keyed on .dag vocabulary (is_container_type reads std.types container_type_arity), so Vec and BTreeSet, the Rust spellings of List and Set, pass a filter that exists precisely to remove host-realized names. Verified both halves against the code before taking the correction. It matters because it moves where a repair goes: narrowing the gate would delete genuine emitter-attested candidates and leave the real source untouched. 2. THE DIAGNOSTIC MATCH HAD A WILDCARD, which is the defect this change exists to repair, in the change itself. The coproduct now carries THREE not-applicable arms against two genuine drops, so a '_' makes the next drop arm silent by default -- total at the level examined, blind one level down. Every non-reporting disposition is now enumerated, so a sixth arm fails to compile here instead of inheriting 'produces no diagnostic'. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ll target vocabulary
I generalised from the head of a sorted list -- the rule I had derived from the
'-' rows this morning and then broke on the population I derived it from.
deep-ant-102 pushed back on the census SCOPE and smart-ram-730 relayed it; both
halves verified against the code before taking it.
THE TRAP: the census invocation passes --source-root dag --source-root src/v2,
but the SUBJECT is regen_input_sources, whose roots are SeedV1 and DagCorpus
(cli_run regen_source_roots) and exclude src/v2 entirely -- stage0 IS the v1 seed
and a seed reaching into src/v2 would depend on the successor it bootstraps
toward. The source-root FLAGS and the regen SUBJECT are not the same thing.
So registry-absent conflates two classes:
(a) EXTINGUISHED Vec, bool, i64, BTreeSet -- no .dag declaration exists or
can; render_rust_type minted the spelling.
(b) OUT-OF-CLOSURE empty_map 33 (v2.std.collection), Optional 25 with Present
47 and Absent 13 (v2.std.optional) -- REAL .dag names whose
providers exist and were not selected in. Verified by
reading both declarations.
Class (b) is precisely the closure-conditioned population this change exists to
surface, sitting inside rows I had written off as unfixable. The proportion is
UNMEASURED -- about twelve of 63 names were examined -- and the carrier says so
rather than inferring it.
WHAT DOES NOT CHANGE: the flip, which rests on an authored fixture RED and not on
the zero; and keeping ProviderUnknown unwired, which is justified by class (a)
alone -- a permanently-false report on those rows trains readers to ignore the
channel whether or not part of the population is movable.
WHAT CHANGES: registry-absent is ENTRY-RELATIVE, not a fixed target, and its
trigger is now that class (a) leave the arm rather than that the whole population
be dismissed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ither as a proportion
Refinement from smart-ram-730 and clever-boar-140. My carrier said 'roughly
twelve of the 63 names were examined' -- a figure I inherited rather than
verified. What is actually established:
BY ROW immovable names dominate: Vec 88 + bool 73 + Option 50 + i64 48
of 473. Verified here -- none of Vec, bool, i64, BTreeSet, Fn,
u8, serde_json has any .dag declaration in the tree.
BY DISTINCT NAME the examined sample is 4 of 63 and ALL FOUR ARE MOVABLE.
Those point opposite ways, and the structure is why the population was misread
twice: high-count immovable names at the head, movable names in the tail with
small counts. empty_map's 33 rows were the THIRD-LARGEST count and were still
classified as target vocabulary on the first pass. Fifty-nine names remain
unexamined by anyone, and the carrier now forbids quoting either figure as a
proportion.
Also records the variant half, which is structural rather than incidental:
Present and Absent are Optional's VARIANTS, so a consumer key reading a
declaration index's field alone reports no-provider-anywhere for every
variant name in the corpus. The key must read declared UNION variants. That
reading is clever-boar-140's, recorded as attribution rather than as something
this module verified.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… arm's ordering clever-boar-140 withdrew the corroboration I objected to and settled the question from the producer instead: build_item_info emits one ItemInfo per TOP-LEVEL ITEM, no arm descends into a coproduct's children, and the single item_registry insert is keyed on that name -- so a variant name is absent from the registry under EVERY closure, not merely this one. Verified against both sites before recording it. THE TWO FACTS COMPOSE, and the composition explains why Present and Absent sit under OUT-OF-CLOSURE rather than under EXTINGUISHED: this PR's fifth arm is tested BEFORE the registry lookup, so a variant whose parent is IN closure is delegated and never reaches the registry. The registry's structural inability to hold variants surfaces only when the parent is OUT of closure and type_summaries cannot recognise the name as a variant at all. That is precisely why my four names could not discriminate the variant-set reading from the closure reading, and why the structural argument was needed rather than the sample. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Generation 1 reaches first_generation_equal=true; export_unproven=0 and provider_unknown=0 (unwired) on the regen seed closure. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…-absent's name
Found in review by clever-boar-140, who owns the coproduct: the Absent arm of the
parent lookup handed back CandidateRegistryAbsent. Reaching it means THIS IS KNOWN
TO BE A VARIANT and its parent is not established -- while registry-absent says the
bare-name REGISTRY holds no entry, a statement about a different map, reached by a
different route, with a different remedy. A reader auditing that row would go
looking at the registry, where the missing fact does not live. Two states
distinguishable at the point of collapse, collapsed anyway -- the same shape my
wildcard removal one function down exists to prevent, left standing one function up.
CHECKING ITS REACHABILITY SURFACED THE SHARPER HALF. derive_variant_to_enum
inserts the EMPTY STRING as the parent when one variant name appears in two enums.
So the lookup answers Present with a parent naming nothing, and the arm I wrote
would have produced CandidateVariantDelegatedToParent { parent_enum: "" } -- a
delegation to no one, wearing the very payload that was supposed to make the arm
honest. That is the top-as-ignorance shape inside the fix for a conflation.
That case is REACHABLE; variant-name collision across coproducts is real enough
that the compiler carries a VariantCollision diagnostic for it. The Absent case is
not, while both this predicate and the parent map derive from the same EnumRepr
summaries -- and it routes to the new arm anyway, because a quiet guard should say
what it means rather than borrow another arm's name.
CandidateVariantParentUnresolved, with a census column, an enumerated
no-diagnostic arm, and two witnesses: a fixture authoring the collision directly
(RED against the arm-less form, which delegated to the empty string), and one
asserting the disposition never reports as registry-absent.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The .dag gained CandidateVariantParentUnresolved and the variant_parent_unresolved census column after the previous regen, so the committed mirrors carried five arms where the authority declares six. Review 56923 reported this as two findings, and they are one: it names a behavioral defect (the Rust dispatch collapses the ambiguity-sentinel and Absent cases) whose cause is structural (the arm is not declared in that file at all). The distinction matters for the remedy -- a collapse is fixed by descending a match, an absence only by regen -- so anyone reading the first finding literally would have searched for an arm to split in a file whose type has no sixth arm to split. Emitted by generation 0 from 157cef3; the two drifted files are exactly the two the sixth arm touches. v1_std_core.rs does not drift, which is the expected result: the arm is a 05_emit_rust disposition, not a 00_core diagnostic variant.
… a second closure returned 87, not 0 The flip to blocking was approved on a measurement of the regen seed closure, where CandidateExportProofFailed's population is zero. The required build lane also runs a v2-emission phase over a different closure -- entry:src/v2/compiler/00_compile.dag, 169 modules -- and there the population is 87. Run 33111325404 at b331e24 refused that phase and reddened the required check. The flip condition was "population over a NAMED CLOSURE is zero AND a discriminating RED is authorable". Both halves held and the conclusion was still wrong: the zero was a property of the closure, not of the arm, and a per-closure zero licenses nothing about another closure. That is the denominator error this same carrier already names one clause down for the sibling arm -- registry-absent is entry-relative rather than a fixed target -- and the reasoning was available for this arm and not applied to it. The bounded sequence ruled for this work said count == 0 flips and count > 0 is the burndown roster at identity grain. The terminal event has fired with the second answer, so 87 is the roster and the arm stays advisory until it burns down. What the brief asked for is unchanged: the diagnostic is still typed, located and counted, so the silent omission is closed. Severity decides whether the line stops, not whether the omission is visible. The falsification is recorded in the carrier rather than the trigger being repointed, and the corrected condition is stated: the population must be zero over every closure a required phase compiles.
…g them smart-ram-730's point: 'every closure a required phase compiles' is a set that moves. It grew when #9035 added the v2-emission phase and again when that phase's subject widened from dag/std/abi.dag to the v2 pipeline root. A described set leaves a future phase addition to whoever remembers; a named one makes it visibly re-open the flip question. Also records that only two of the three are measured for this arm (0 and 87), so even the corrected condition is not currently evaluable, and that deep-ant-102 delivered this exact objection before the flip and it was acknowledged and not carried. A dropped warning and a missing insight have different remedies.
… string The previous commit's note embedded a quoted phrase inside a double-quoted string literal, so the parse ended mid-sentence and the module index refused the whole file. Caught by regen, five minutes into a remote build, at a byte offset 46420 that names the position and not the cause -- the error reads 'expected item declaration' because the parser was looking at prose it had fallen out of a string into.
Drift is exactly the two files the change touches: v1_std_core.rs carries the three severity classifiers gaining a ReferenceDerivedImportExportUnproven arm, and the witness mirror carries the _is_blocking -> _is_advisory rename. v1_compiler_emit_rust.rs correctly does not move -- the demotion is a 00_core severity fact, not an emitter one. Emitted by generation 0 from 13ea193; the run reports first_generation_equal=true after installing the candidate.
…eneration All three conflicts were GENERATED mirrors; zero .dag conflicts, so the authorities merged clean and only their projections collided. The generated-artifact driver refuses rather than writing markers, leaving the ours side unmerged with a regeneration recipe -- hand-resolving would produce bytes that satisfy git and then diverge from the emitter, which required-regen compares byte-for-byte. Neither side could be taken wholesale: main added CallTargetIdentity (#9486) so main's hand-Rust needs main's mirror, while this branch's cli_run.rs arms need this branch's. Both pure resolutions fail to compile before regen can run. So stage0 was reduced to EXACTLY main's -- main's mirrors, these two cli_run.rs arms temporarily stripped -- which builds, and the merged .dag emitted the union. The mirrors here are what the compiler produced, not what anyone assembled. Six files drift, not the three that conflicted: adding variants to CompilerDiagnostic changes emitted match arms in every emitter that matches on it, so emit_core_support, emit_go and emit_python move too. The set of files a merge CONFLICTS on and the set a regen CHANGES are different sets, and only the second is the truth.
Same resolution as the previous merge: the single conflict was a generated mirror, zero .dag conflicts, so stage0 was reduced to exactly main's and the merged .dag emitted the union. Six mirrors move again -- emit_core_support, emit_go and emit_python alongside the three that git flags -- because adding CompilerDiagnostic variants changes emitted match arms in every emitter matching on it. Picks up #9461, which filters a module's own coproduct-variant names out of the emitter's import candidates. That is this branch's candidate set, so the export-proof population is re-measured on this tree rather than carried across; the prediction published before measuring is that the 87 is unchanged (all dotted cross-module, where #9461 removes bare local self-references) and that registry-absent shrinks.
…storing a pre-merge copy The previous commit restored cli_run.rs wholesale from the snapshot taken before stripping the arms for gen-0. That snapshot predates main's change to record_from_module, which gained an &Rc<OccurrenceTransport> parameter, so restoring the whole file silently reverted main's edit to a file that had auto-merged cleanly. rustc caught it as E0061. The arms are a two-hunk addition, not a file. Re-applied onto main's version beside their sibling UnlistedVariantValueUse arms.
reference_derived_use_lines_note described the PRE-CHANGE world inside the change that closes it: 'typed refusal at step-2 is future work', in a branch that lands CandidateExportProofFailed and ReferenceDerivedImportExportUnproven at seven sites each. A reader trusting the note concludes the wall does not exist in the PR that builds it. Found by smart-ram-730, who raised it from the opposite direction -- they read a note claiming the emission REFUSES and measured blocking=0 against it. That claim turned out to be on an abandoned local lineage rather than this branch, but reading my own note to answer them surfaced the inverse defect, which is mine and materially worse: a false 'it refuses' overstates a wall, a stale 'future work' denies one that is there. The clause now names the disposition and the diagnostic, and says explicitly that the emission is NOT refused -- because 'typed refusal' otherwise implies one. The diagnostic is advisory, so emission completes and produces its files beside it, measured on the required build lane at this branch: entry:src/v2/compiler/00_compile.dag emitted=175 blocking=0. What step 2 closed is the SILENCE, not the emission. Severity stays where it is owned, in v1.compiler.core reference_derived_import_refusal_severity_note. The annotation above the coproduct QUOTED the old wording. It keeps the quote, now marked as superseded, because the before-state is what motivates the arms -- but a quotation that silently tracked the edited note would cite a text that no longer exists. Its 'four things' also became six when the two variant arms landed.
The note text is emitted into the mirror, so editing it necessarily drifts v1_compiler_emit_rust.rs. Two-generation regen at fdf4ccf plus the note commit: gen-0 first_generation_equal=false with drift in exactly that one file, install, REBUILD, gen-1 first_generation_equal=true. The single-file drift was the discriminator this run needed, not just its result. An EMPTY drift would not have been good news: it would have meant the uncommitted edit never reached the runner and the regen had measured a tree without it. Non-empty drift naming exactly the mirror of the edited file is what establishes the measurement was of the right tree, and it doubles as the parse check -- a .dag parse failure returns NO_CANDIDATE, which is how a stray quote in a note surfaced earlier on this branch.
# Conflicts: # src/v1/stage0/src/v1_compiler_emit_rust.rs
… decide The merge of #9551 conflicted on v1_compiler_emit_rust.rs and the generated-artifact driver refused it correctly -- path left unmerged, no markers, regeneration recipe printed. I then seeded the resolution from MAIN's side, and the two-generation regen refused to build it: error[E0599]: no variant named CandidateVariantDelegatedToParent found for enum ReferenceDerivedCandidateDisposition --> v1_tests_claim_reference_derived_disposition_census_witness_test.rs could not compile v1-compiler (lib) due to 19 previous errors Main's mirror predates this branch's dispositions and this branch's witness mirror references them, so that side cannot be a compilable gen-0 seed. THE LESSON IS ABOUT WHAT 'DO NOT PICK A SIDE' MEANS. I took it to mean the final bytes must come from regeneration, which is right, and inferred that the starting seed was therefore arbitrary, which is wrong. Gen-0 runs the COMMITTED mirror to emit the candidate, so the seed must compile -- a side that does not is not a neutral starting point, it is a broken compiler. The choice of seed is not a choice of content and it is not free either. Seeded from this branch's side instead, which is main's #9551 bytes plus the note edit -- established rather than assumed: fdf4ccf regenerated with EMPTY drift, so its mirrors already equalled main's, and 037cda8 added only the note text on top. Regen output follows and is the authority.
briansrls
marked this pull request as ready for review
August 28, 2026 05:26
Contributor
Author
|
This PR contains no content that is not already on main. Recommending close-as-duplicate rather than a fix push.
Measured, six of the seven files this PR touches are byte-identical to main ( The seventh differs only because the branch is behind main, not because it carries a remainder: all eight lines it proposes for The failing checks are also not this PR's. They come from run
So there is no defect here attributable to this diff, and no diff to attribute one to. Pushing a change to make these checks green would be manufacturing work against a false premise on both counts. — sent from smart-ram-730 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a3347f745d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Comment on lines
+3787
to
+3788
| if is_known_variant(type_summaries: type_summaries, name: name) { | ||
| match map_get(variant_to_enum, name) { |
There was a problem hiding this comment.
When a candidate name is both a top-level declaration and a variant anywhere in the compile closure, this closure-wide is_known_variant check bypasses the registry entry for the declaration and delegates the candidate to the unrelated variant's parent. Such collisions already exist in the corpus—for example, std.syntax.BinOp is a type while extdeps.languages.typescript.program.TsExpr has a BinOp variant—so an unimported reference to the type in a closure containing both no longer reaches CandidateSurvived; its derived use-line is omitted and the emitted Rust can fail to resolve the declaration. Preserve the resolved declaration identity, or use variant fallback only when the candidate is actually bound as a variant.
Useful? React with 👍 / 👎.
Contributor
Author
|
|
Contributor
Author
|
Note on the approval above: it reviewed the three-dot diff, which after a squash merge still shows the entire branch. Everything it describes — I checked whether the standing approval makes merging this a hazard. It does not. Merging is a no-op: The merge result is byte-identical to current main. So this is pointless rather than harmful — no revert risk, no re-application. I raise it only because an APPROVE sitting above a duplicate finding reads as a reason to merge, and the reason it is safe is worth stating explicitly rather than leaving to inference. Recommendation is unchanged: close as duplicate. The remaining red is still the inherited floor cost fail-stop that #9517 closes, not anything here. — sent from smart-ram-730 |
This was referenced Aug 28, 2026
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.
Auto-opened by session-dashboard for session
clever-ibex-894.Pushing to
session/clever-ibex-894advances 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