fix(resolve): extension-registry follow-up cluster (4 fixes)

[Hessesian]

Summary

Follow-up to #321 — fixes the 5 items that PR deliberately parked to keep its own measurement
attributable. Four tasks:

• Task 1: resolve_chain's four IO-policy tails now check the Kotlin built-in→platform-type
  fallback (resolve_kotlin_builtin_type_platform_equivalent) before trusting a
  lookup_definitions/tie-break result, for the 7 of 22 names in
  KOTLIN_BUILTIN_TYPE_PLATFORM_EQUIVALENTS that were losing to a same-named kotlin-stdlib JAR
  decoy (List, MutableList, MutableSet, MutableMap, MutableCollection,
  MutableIterable, MutableIterator). Ships a path-keyed memo for
  detect_android_sdk_source_paths in the same commit — the reorder puts an unmemoized
  filesystem-scanning call on a much hotter path, and it turns out that call was already being
  hit ~53k times per corpus run even before this branch.
• Task 2: new extension_entry_is_in_scope wrapper (the shared extension_is_in_scope
  predicate, which has 4 unrelated callers, is left untouched) adds Kotlin-default-import-package
  awareness, so kotlin.text/kotlin.collections extensions like isNotEmpty/forEach are
  recognized as in-scope without needing an explicit import.
• Task 3: implicit_receiver_extension_match gets the same overload-disambiguation fix fix(resolve): extension-registry overload-collapse family (4 fixes) #321
  shipped elsewhere (new select_extension_symbol helper, split out of the existing
  select_extension_symbol_range). Also documents a closed decision: rename now correctly
  refuses on a same-arity extension collision (a consequence of fix(resolve): extension-registry overload-collapse family (4 fixes) #321's own fix) — one comment,
  no behavior change.
• Task 4: find_extension_fn_return_type_scoped gets the same disambiguation fix (reusing
  Task 3's helper) plus a separate bug: two early-return ?s that used to abort the whole
  function on one unloaded file now continue past that entry instead.

Full design, evidence, and two rounds of independent adversarial review: see
docs/superpowers/plans/2026-09-16-extension-follow-ups-plan.md.

Real-corpus measurement — cumulative, not pairwise

Each task measured against its own immediate predecessor. The final whole-branch review ran the
number nobody had: main (before this branch) → this branch's tip, one pass, same warm cache.
The individual tasks' pairwise deltas do not compose — naively summing them suggests an
improvement; the real cumulative number is a real, understood cost:

metric	before	after	Δ
member recall	91.6%	91.6%	flat (masks +887 member refs — see note)
member Gap (actionable)	7486	7169	−317
FilteredCandidate	6305	6754	+449
wall clock	4:48.57	5:00.59	+12s (+4.2%)

Why FilteredCandidate rose, traced not guessed: Task 1 correctly anchors List on the real
java.util.List (was a supertype-less JAR decoy), which lets resolve_qualified's supertype
walk reach Collection/Iterable for List-typed receivers for the first time. Task 2 makes
kotlin.collections-packaged extensions at those levels in-scope. Compounded, more real
candidates now survive to the walk's own by-design "both returned, caller's shape filter
disambiguates" policy — and land in FilteredCandidate when that filter can't narrow to one.
Neither task's own diff review could see this; it only shows up at whole-branch scale.

Gap top-20 names that left as intended: firstOrNull (−122), isNotEmpty (−95), forEach
(−80), filter (−65), map (−64), contains (−61). <bare>.List's 2-distinct-location
ambiguity also disappeared. The member-recall percentage staying flat is a reclassification
artifact (bare refs fell by exactly 887 — the same denominator trap this project has hit before),
not a null result — absolute counts (Gap −317, CstResolved +755) are the honest read.

This is a real, accepted cost, not a bug: reaching more real candidates that a shape filter
genuinely can't disambiguate is more honest than the previous behavior (many of those receivers
resolved to nothing at all before this branch). rename.rs's existing ambiguous-refusal
comment was updated to reflect the new frequency, not just restate the old reasoning.

Follow-ups found, deliberately not fixed here

• Three of Task 1's four reordered tails (Full, NoRg, HierarchyAmbiguitySafe) ship with no
  direct test coverage — only IndexOnly is tested/benchmarked. Low measured risk (all four
  arms' inserted code is identical), a NoRg test is a cheap named follow-up.
• An allocating Language::from_path call runs before a cheap array scan in the new scope-check
  gate, on a hot per-entry loop — same category Task 1 already fixed elsewhere, Minor severity.
• select_extension_symbol's exact-match disambiguation silently degrades to first-match when
  two overloads' truncated detail strings collide — worth a doc-comment sentence.
• implicit_receiver_extension_match picks the first shape-accepting entry on genuine ambiguity
  rather than declining (pre-existing asymmetry with fix(resolve): extension-registry overload-collapse family (4 fixes) #321's decline-on-ambiguity policy
  elsewhere, made more reachable by Task 3's own fix).
• The FilteredCandidate rise points at the plan's own already-scoped-out follow-up: arity-aware
  extension-return-type selection needing a CallShape threaded through the Resolver trait —
  this branch's own result makes that more urgent, not less.

Test plan

• cargo test — 1966 passed, 0 failed, 3 ignored (plus integration suites, all green)
• cargo clippy --all-targets -- -D warnings — clean
• cargo fmt -- --check — clean
• Each task independently reviewed (spec compliance + code quality); Task 4's fixture design
  was the site of a real blocker found by an independent adversarial plan review (false-green
  tests, one unfixable as originally designed) — rebuilt, and independently re-verified
  red-then-green by both the plan's own drafting agent and the task reviewer, each in a
  separate throwaway worktree
• Final whole-branch review (opus): ready to merge, no Critical findings, the cumulative
  real-corpus number above is that review's own finding

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Critical visibility and Java-language fallback issues remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

This PR improves Kotlin extension resolution, platform-type fallback, overload handling, and inference robustness.

Changes:

• Prioritizes platform equivalents and memoizes SDK source discovery.
• Adds default-import-aware extension scoping.
• Improves overload selection and continues past unusable inference entries.
• Adds regression tests and supporting documentation.

File summaries

File	Reviewed changes
src/resolver/tests.rs	Resolver regression coverage.
src/resolver/resolve.rs	Platform fallback resolution.
src/resolver/platform_types.rs	SDK source-path memoization.
src/resolver/infer.rs	Extension scope and inference fixes.
src/resolver/infer_tests.rs	Inference regression tests.
src/resolver/imports.rs	Default-import package detection.
src/resolver/extension.rs	Overload-aware extension selection.
src/features/rename.rs	Ambiguity refusal documentation.
docs/superpowers/plans/2026-09-16-extension-follow-ups-plan.md	Design and measurement documentation.

Review details

Suppressed comments (5)

docs/superpowers/plans/2026-09-16-extension-follow-ups-plan.md:1187

• This plan snippet asserts Some("T?"), but the checked-in regression test intentionally strips trailing nullability and asserts Some("T") (src/resolver/tests.rs:11465-11470). Following the plan's example would produce a failing test even when the scope fix is correct; update the snippet to match the actual helper contract.

        Some("T?".to_owned()),

docs/superpowers/plans/2026-09-16-extension-follow-ups-plan.md:367

• This plan repeats the same inaccurate caller-count rationale as the implementation comment: nullable_call_diagnostics is an extension caller, so only two of the six callers are unrelated to extensions. Rewrite the explanation in terms of extension-registry consumers versus the three callers with different reachability contracts.

/// Deliberately NOT folded into [`extension_is_in_scope`] itself: four of that
/// function's six callers are not about extensions at all
/// (`candidate_declaration_is_reachable`, `Indexer::jar_candidate_is_reachable`
/// and `nullable_call_diagnostics`' stricter own rule), and widening the shared
/// predicate would change bare-name JAR candidate preference corpus-wide.

src/resolver/extension.rs:47

• This helper is now called once per registry entry by implicit_receiver_extension_match, but it materializes every shape-matching declaration into a new Vec on each iteration. That adds an allocation and forces a full scan of all overloads for every entry; the old path stopped at the first match without either cost. Use two non-allocating find passes (exact detail first, then the first shape match) or otherwise avoid collecting the matches.

    let declaring_symbols: Vec<_> = file_data
        .symbols
        .iter()
        .filter(|symbol| {
            crate::resolver::infer::extension_declaration_matches(
                symbol,
                name,
                receiver_base,
                container,
            )
        })
        .collect();

src/resolver/infer.rs:1881

• This rationale says four of the six callers are unrelated to extensions, but the cited list contains only two such callers; nullable_call_diagnostics is itself an extension caller with a stricter contract. The inaccurate count makes the wrapper's blast-radius justification misleading. State that only the three extension-registry consumers should use the wrapper and that the other three callers have different reachability contracts.

/// Deliberately NOT folded into [`extension_is_in_scope`] itself: four of that
/// function's six callers are not about extensions at all
/// (`candidate_declaration_is_reachable`, `Indexer::jar_candidate_is_reachable`
/// and `nullable_call_diagnostics`' stricter own rule), and widening the shared
/// predicate would change bare-name JAR candidate preference corpus-wide.

src/resolver/platform_types.rs:187

• The memo is keyed only by the path, while WorkspaceRoot::set bumps its generation even when the same path is configured. If SDK sources or local.properties change after the first probe, reinitializing or rescanning that same workspace keeps returning the old cached paths, so built-in resolution remains wrong until the root string changes. Key this cache by the workspace generation or invalidate it when same-root configuration changes.

    if let Some((cached_root, cached_paths)) = detected.as_ref() {
        if cached_root == workspace_root {
            return cached_paths.clone();

• Files reviewed: 9/9 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.