Valid references remain unresolved across declaration groups, type relations, scopes and imports #536
Labels
No labels
code-review
correctness
dos
performance
security
severity/high
severity/low
severity/medium
tech-debt
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
h-dv/code-index#536
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Scope (consolidated 2026-11-12)
Names that the language binds can remain unresolved when declarations are split, a receiver uses a type relation, or an import needs its full module path. Agents then miss real callers, rename sites and production dependents. Resolver identity must follow the language’s declaration groups, visibility and import rules. Resolution figures are the measuring instrument for this work and must separate actual misses from local, external and misclassified rows.
Priority: High · Risk: wrong answer · Size: L
Merged into this ticket: #538 (Type relations and member dispatch), #541 (Visibility and exact qualifiers), #543 (Import and module routes), #549 (Truthful resolution populations)
Done
crates/indexer/src/index/member_lookup.rsgroups same-file Rust type/impl and Ruby blocks plus C# partial FQNs, and traverses resolved supertypes; this is narrower than a shared declaration-group identity.selectincrates/indexer/src/index/namespace_types.rs(58801d26/d11a35fb); direct-base repairs are recorded in9e410c1c.named_const_fixture,resolved_importer_e2e,embedded_typescript_importersandnon_script_targets_use_script_pathsincrates/daemon/tests/script_import_correctness.rscover the .mjs/.ts regression and script routes.a_global_receiver_keeps_its_proven_inherited_memberincrates/indexer/tests/global_roots.rs; this does not establish trait/interface completeness.Remaining
Declaration identity
Type relations and receiver flow
Scope and exact qualifiers
Full-path imports and dependencies
Resolution populations
Acceptance
Suggested order
Original report
Summary
Several languages split one logical type into several declarations: TS declaration merging, C#
partial, Ruby class/module reopening, a Rust type and itsimplblocks, and a TSdeclare moduleaugmentation. The resolver and the name lookup treat each piece as a rival candidate. #523 reported theget_symbolrefusal for Rust; the per-language review shows that the bigger cost is on the resolution side, where whole public APIs get zero refs.2dcfc615)export interface X…; export const X: core.$constructor<X>. 24/24 sampled merged symbols haveref_count 0:ZodString,ZodType,ZodObject,$ZodError, … Fixture:interface Foo+const Foo, anduseFoo(f: Foo): Fooin the same file stays name_fallback, while the unmergedBarbinds 3/3.SqlMapperis 26partialfiles:get_symbolrefuses with 27 candidates, even qualified (Dapper.SqlMapper).SqlMapper.AddTypeHandler/ResetTypeHandlers/PurgeQueryCache/Identity: 0/70 qualified calls resolved. Type refs: 16/167.get_symbol "Sinatra::Base"refuses (base.rb:971vs its reopening attest/test_helper.rb:37).Sinatrahas more than 20 candidates. A method defined in one reopening is invisible to calls from another reopening in the same file (prove_bare_receiverskeys by container index,ruby.rs:667-700).impl.declare module "zod/v4" { interface ZodType {…} }inv4/classic/tests/prototypes.test.ts:4-9becomes a standalone interface, and 12z.ZodTyperefs in other test files bind to it, while the realZodType(classic/schemas.ts:78) has 0. That is a wrong bind.flask.blueprints.Blueprint) are refused, and the hint suggests the Rust-styleContainer::X.Proposal: declaration groups (one mechanism)
partialby FQN; Ruby same qualified name and kind; Rustimplwhose self type is the type; PHP and Python none.get_symbol,find_referencesandcheck_renamereturn the group (primary declaration plusparts: [...]).Dapper.SqlMapper,flask.blueprints.Blueprint,Sinatra::Base).Acceptance
ZodString/ZodTypeget resolved refs.ZodType.SqlMapper.*qualified calls resolve.get_symbolsucceeds forSinatra::Base,SqlMapperandStore.precision_gatedecoys for two genuinely different same-name types.Supersedes the resolver half of #523, which stays as the narrow
get_symbolcase.Filed from the per-language review on 2026-11-09: 8 agents, one per language plus one for Vue/Svelte/XAML/timeline, run against copies of the pinned corpus repos (
tests/corpus/corpus.toml) using installed build2dcfc615, which differs from master only by XAML/CI commits. The top claim of every issue was spot-checked in the main session. Artifacts live under the review session's scratchpadlang-out/<lang>/and are available on request.Declaration groups: TS merging, C# partial, Ruby reopening and Rust impl are rival candidates — zod v4's API has 0 resolved refsto Valid references remain unresolved across declaration groups, type relations, scopes and imports