6 commits

Author	SHA1	Message	Date
Gergő Magyar	9c24e3459e	fix(rust): qualify items by their enclosing mod chain so same-named ones stay distinct (#2742) (#2745) ... * fix(rust): let the qualified-call filter see inline modules The negative filter added in #2741 builds its set of known module names from FILE PATHS, so an inline `mod x { … }` — which appears in no path — was absent from it. Every module-qualified call into an inline module was therefore rejected before any candidate channel ran, which is a hole in that optimisation rather than in the resolution logic it guards. The per-pass index now unions the file-derived names with inline module names taken from the scope model: a `mod` declaration binds a `Namespace` def locally in the declaring scope, and that binding is the only place an inline module's name exists. Collected in the same walk that already builds the module → scope map, so it costs no extra pass. Found while fixing #2742, where a correctly resolved call into `mod inner { … }` still could not reach its target. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(scope-resolution): try the namespace-prefixed node key before the bare one `resolveDefGraphId` looked up the plain `qualifiedName` key first and only retried with the `namespacePrefix`-qualified key afterwards. For the defs that carry a prefix the qualified name is a bare TAIL, so the plain key happily matched a same-named item at a different namespace depth in the same file and returned it before the more specific retry was ever reached. The namespace-prefixed key is strictly the more specific of the two, so it is now tried first. Where no such node exists the lookup falls through to exactly the previous order, which keeps the #1982 behaviour this retry was added for. Without this, a call into `mod inner { fn dispatch }` resolved to the correct definition and then mapped it onto the crate-root `fn dispatch` node — the self-loop #2742 describes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): qualify items by their enclosing mod chain so same-named ones stay distinct (#2742) Node identity is `<label>:<file>:<qualifiedName>` and carried no module path, so an inline `mod inner { fn dispatch }` and a crate-root `fn dispatch` in the same file collapsed onto `Function:<file>:dispatch`, first-wins. Resolution already picked the right definition — the target simply was not representable, so a correct resolution still rendered as a self-loop and `impact` reported the real callee as unreached. The mechanism already existed: `qualifyRustImplTargetByModScope` has walked `mod_item` ancestors for impl targets since #1982. Generalised to `qualifyByEnclosingModScope` and applied to free items, so `mod inner { fn dispatch }` becomes `Function:<file>:inner.dispatch`. Keyed purely on the `mod_item` node type, exactly as the impl qualifier already was, so it is a no-op for every language whose grammar has no such node. Two constraints found by tests rather than by reading, both now encoded: - The helper normalised `::` to `.` unconditionally. With no enclosing `mod` that rewrote a top-level `impl a::Inner` from `a::Inner` to `a.Inner` and moved its node id away from the one the HAS_METHOD owner edge emits, breaking the #1975 scoped-impl ownership. It now returns raw text untouched when there are no mod segments, which also makes the change strictly additive for every id that has no enclosing module. - Qualification is scoped to items with no enclosing class/impl. A method already carries its owner's name, and that owner's id is mod-scoped by the impl qualifier, so qualifying the method again breaks the same byte-for-byte agreement. Same-named methods on same-named types in sibling modules therefore still collapse — a narrower residual than the free-item case fixed here, and one belonging to the owner edge rather than to this path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(storage): bump schema versions for the mod-qualified Rust node ids (#2742) `INCREMENTAL_SCHEMA_VERSION` 24 -> 25 and `SCHEMA_BUMP` 31 -> 32. Node ids change for every Rust item inside any `mod` block, and `#[cfg(test)] mod tests` makes that close to every Rust repository. A pre-v25 index therefore holds ids an incremental top-up cannot reconcile — the old nodes would simply be stranded — so the reuse gate has to force a full re-analyze. The qualified name is computed in the parse worker, so a warm parse cache would likewise replay the old unqualified ids and keep the collapse. This branch originally claimed v24; #2708 took that number and merged first, so it is renumbered to v25 here. That is exactly the collision the v29 note in parse-cache.ts warns about, and re-checking against origin/main at rebase time rather than at branch time is what caught it. #2708 did not touch `SCHEMA_BUMP`, so 32 is free. The version-pin test moves with the bump by design, including the new pre-v25 row in the reuse-gate table. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): stop mod-qualifying container ids while their owner edges stay bare (#2745 review) #2742 re-keyed Rust node ids by the enclosing `mod` chain. The mint moved; the owner-edge anchor did not. `findEnclosingClassInfo` mints a member's owner id from the container's BARE `nameNode.text` and only follows a qualified shape when the provider sets `classExtractor.qualifiedNodeId`, which Rust does not. So every `struct` / `trait` / `enum` / `impl` declared directly inside a `mod` got a node id that none of its member edges pointed at. Five lines of idiomatic Rust were enough: pub mod engine { pub struct Config { pub retries: usize } } NODE Struct:src/lib.rs:engine.Config DANGLING HAS_PROPERTY Struct:src/lib.rs:Config -> Property:src/lib.rs:Config.retries The rows are discarded by the IGNORE_ERRORS COPY retry, so the struct silently lost every field. A trait impl inside a `mod` additionally dropped its METHOD_IMPLEMENTS edge outright. The same gap put `impl a::Inner` inside a `mod` back on the #1975 rake that `qualifyByEnclosingModScope`'s own docblock warns about. The impl-target branch deliberately fires only for an UNSCOPED `type_identifier`; the new gate had no such restriction and picked up the scoped targets that branch had just excluded, minting `Impl:<file>:outer.a.Inner` against an anchor still reading `Impl:<file>🅰️:Inner`. The member side was already excluded via `!enclosingClassInfo`. This adds the owner side, gated on `MEMBER_OWNER_NODE_TYPES` — derived from `CLASS_CONTAINER_TYPES`, which is already the single source of "this node type owns member edges" and already carries an INVARIANT note binding it to `CONTAINER_TYPE_TO_LABEL`. A language adding a container therefore cannot gain a mismatched id shape here without also failing that invariant. Keyed purely on tree-sitter node types, so no language name enters shared ingestion. `union_item` is listed too: its fields are captured as Property but it is not a recognized owner, so they carry no HAS_PROPERTY edge and cannot dangle — it is here so a union's id keeps the same shape as the struct beside it. Containers still collapse across sibling modules, exactly as before this fix. That residual belongs to the owner edge, and is not worked around here. Regression tests use the UNFILTERED `findDanglingEdges(result)`. Every other dangling assertion in `rust.test.ts` passes `['HAS_METHOD']`, which is precisely why the HAS_PROPERTY breakage shipped with a green suite. They assert the NODE id rather than only the edge's anchor, because the anchor was already bare while the bug was live — an edge-only assertion passes in both builds. All four fail when the new gate clause alone is reverted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z * fix(rust): resolve modules nested inside an inline mod (#2745 review) The #2730 self-loop survived one `mod` deeper: pub mod outer { pub mod tools { pub fn dispatch() {} } pub fn dispatch() { tools::dispatch(); } } CALLS outer.dispatch -> outer.dispatch <- the #2730 symptom NODE outer.tools.dispatch <- correct target, unlinked Two gates were blind to a nested inline module, so the hook refused and the shared lexical tier bound the call to the enclosing same-name `dispatch`: `knownModuleNames` was collected by walking `moduleScopeByFile`, which maps a file to its ROOT `Module` scope only. A `mod` nested inside an inline `mod` binds in the parent module's scope, so the walk saw depth-1 inline modules and missed every nested one — `tools` never entered the set and the negative filter rejected the qualifier before any candidate ran. `declaresSubmodule` had the same root-only assumption, so even with the name known the candidate `outer::tools` was never yielded. Both now read the def index. Names come from every `Namespace` def; inline module PATHS are derived from the members' `namespacePrefix` rather than from the `mod` defs, because a `mod` def carries no nesting information of its own — inside `mod outer { mod tools { … } }` the inner def is `qualifiedName: 'tools'` with NO `namespacePrefix`, while every def within it is stamped `outer.tools`. A `Namespace` scope also owns its OWN def rather than its children's, so the scope tree cannot answer this either: the `mod outer` scope lists `outer`, never `tools`. Restricted to non-empty prefixes, so this stays a DECLARATION check. Including file-derived modules would let an undeclared or `cfg`-gated file on disk outrank a real `use` binding — the regression #2741's review already fixed once. File-backed submodules therefore keep going through the binding check. A module with no defs at all is absent from the set, which is harmless: it has no member for a qualified call to resolve to. Cost is one pass over an already-resident def index, memoized per resolution pass on the existing WeakMap — the same order of work as the binding walk it replaces, and it subsumes it. `isLocalNamespaceBinding` was going to single-source the duplicated "locally declared submodule" predicate the review flagged; deriving paths from members removed the second copy outright instead. Regression fixture covers depth 2 and depth 3, so the fix is depth-agnostic rather than depth-2 special-cased. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z * fix(rust): let an imported type outrank a same-named module (#2745 review) Widening the negative filter to inline `mod` names let a type-qualified call through whenever a module happened to share the type's name. The crate-root-relative candidate then captured it: // src/lib.rs pub mod Buffer { pub fn with_capacity() -> usize { 111 } } // src/b.rs use crate::c::Buffer; // the real target lives in c.rs pub fn call() -> usize { Buffer::with_capacity() } base: (no CALLS edge — unresolved) PR: CALLS b::call -> Function:src/lib.rs:Buffer.with_capacity <- fabricated `ids.ts` states the doctrine this broke: a missing edge is the correct failure direction for a graph whose consumers include `impact`; a fabricated caller is not. The base produced the missing edge and the PR produced the fabricated one. That third candidate is the loosest of the three — a guess at a crate-root-relative path the caller never wrote, kept for 2015-edition style. In Rust 2018 a bare first segment resolves in the CALLER's module, so a local binding for that segment settles the question: it is now skipped when the head names anything non-module in the caller's own module. Candidates 1 and 2 are untouched, and they run first, so the legitimate `use crate::tools;` path is unaffected. The binding lookup goes through `lookupBindingsAt`. A first attempt read `Scope.bindings` directly and the guard never fired: a `use` binding is finalize OUTPUT and absent from the scope's own local table, which is exactly the imported-type case being guarded. Contract I8 in `contract/scope-resolver.ts` requires that channel anyway. The regression test asserts the forbidden TARGET rather than an empty edge set, and separately asserts the module member still exists as a node — otherwise the test would pass just as well if the call went unresolved for some unrelated reason, or if the module node disappeared entirely. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z * fix(scope-resolution): try the namespace-prefixed name on the TAGGED keys too (#2745 review) `resolveDefGraphId` gained a namespace-prefixed retry for the plain qualified key in this PR, but the five tagged keys above it — template constraints, parameter types, parameter shape, arity, template arguments — kept composing from the bare `qualifiedName`. For a namespace- or `mod`-qualified def those keys are simply dead: `node-lookup.ts` registers them under the QUALIFIED name (`inner.dispatch#0`) while this side built `dispatch#0`. The keys exist to separate overloads, so a mod-scoped overload set was relying on whichever later key happened to catch it. Verified as a miss rather than a mis-hit before changing anything — an end-to-end run with a crate-root decoy of the same name and arity binds correctly — so this is hygiene, not a live bug. Worth doing while the code is open rather than leaving five keys dead and the behaviour dependent on fallback order. Both name forms now go through one `lookupTagged` helper, most specific first, so a sixth tagged key cannot be added with the bare form only. That also removes the five hand-repeated `qualifiedKey(...)` / `nodeLookup.get(...)` pairs. Also pins the C++ `EXTENDS` retarget this PR's reorder produces. `cpp-two-phase-dependent-base-cross-ns-deep` declares a global `Inner` decoy alongside `ns:🅰️🅱️:Inner`; the base's `qualifiedName` is a bare `Inner` with the path on `namespacePrefix`, so only the prefixed key separates them, and only if it runs first. The improvement was riding unasserted in a Rust-scoped PR. The captures golden covers every `rust-*` fixture, so the three fixtures added by this review series drift it; regenerated with UPDATE_GOLDEN=1. Verified: 785 tests across cpp / csharp / rust resolvers and the callable-id-lockstep unit test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z * fix(rust): keep a mod declared inside a fn from hoisting above the callable (#2745 review) `fn wrapper() { mod helper { fn dispatch } }` minted `Function:<file>:helper.wrapper.dispatch@2:8` — the mod segment composed OUTSIDE the enclosing-callable prefix, inverting the real nesting. Nothing dangled: the `@line:col` suffix already makes a function-local callable's id unique, which is also why the mod segment adds no identity in this position. The path simply read as a lie about the source. It is now skipped rather than reordered — interleaving two qualifier passes to fix the order would be real machinery for a shape whose ids are already unique. Also folds in the three documentation and structure findings from the same review: - The 4-clause gate is extracted to a named `qualifiesByEnclosingModScope`, matching the two conditions directly above it in the same function, which were already named consts. - `qualifyByEnclosingModScope`'s docblock documented only the impl-target contract even though the generalized name has had a second, looser caller since #2742. It now states both, and says which gate belongs to which — that gap is what let the #1975 scoped-impl regression through in the first place. - The "cheap rejection BEFORE any index work" comment was no longer true: `passIndexFor` walks the def index on its first call in a pass. Corrected rather than left to mislead the next reader into thinking the filter is free. What it still buys — skipping the per-site candidate search, the part that scales with the workspace — is stated instead. Verified: 279 tests across the Rust resolver suite and the Rust scope-resolution unit tests. Captures golden regenerated for the extended fixture. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z * test(storage): move main's SCHEMA_BUMP pin to 32 for the mod-qualified ids (#2745 review) `#2736` added a pin asserting `SCHEMA_BUMP === 31` on main, which arrived on this branch through the merge of main while `0062a5c2` had already bumped the constant to 32. Neither side conflicted textually — the pin and the constant live in different files — so the merge was clean and the test failed instead. That is the pin working as designed: it exists so a bump cannot ride along unnoticed, and this is the fifth time a SCHEMA_BUMP collision has been caught by a guard rather than by review. Updated to 32 with the reason recorded inline. `INCREMENTAL_SCHEMA_VERSION` needs no second bump: 25 was introduced by this unmerged branch, so no released index carries it, and its own pin in `call-summary-schema-version.test.ts` is already consistent. Verified: 119 tests across the parse-cache, schema-version, incremental-orchestration and the two identity suites that arrived with the merge. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z * test(bench): rebaseline the Rust capture fingerprint for the three new fixtures (#2745 review) CI caught what I missed: [scope-capture --check] FAIL: rust: capture fingerprint drift (got 05acbaca..., expected 90fda086...) fixture_count 202 `bench/scope-capture` fingerprints the whole `rust-*` fixture corpus, so the three fixtures added by this review series drift it. I rebaselined the `rust-captures-golden` snapshot and stopped there — a new fixture is a call site of BOTH, and updating only one is how this reached CI red. This is the same class as PR #2743's headline finding, from the other direction: an id-shape change makes every synthetic corpus a call site, and the author fixed the unit-test fixture and missed the bench. Here it is a fixture-count change rather than an id-shape change, and the review that flagged the #2743 lead as "REFUTED, bench/ has no Rust node-id corpus" was right about node ids and wrong about the corpus fingerprint. Noted for the next author in the baseline entry itself. Verified as pure corpus growth rather than a capture-logic shift: removing ONLY the three new fixture directories and re-running reproduces the prior fingerprint exactly (196 fixtures, capture_groups_fp 3432), and restoring them gives the new one (202, 3556). `emitRustScopeCaptures` is untouched by this series. Scaling 1.022 local / 1.057 CI, well inside the 1.5 budget. `bench/python-scope` globs `python-*` only and is unaffected; no other bench walks the Rust corpus. `--check` now PASSes for all 15 languages. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GvVxWt1ShhEP8CiMj3b6Z --------- Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 17:08:00 +01:00
Gergő Magyar	df06529950	fix(rust): resolve module-qualified calls against the module tree (#2730) (#2741) ... * fix(rust): resolve module-qualified calls against the module tree (#2730) A Rust call written with a path (`tools::dispatch(..)`) was captured with only its tail identifier, making it indistinguishable from a bare `dispatch(..)`. The scope-chain walk then resolved the bare name lexically and bound it to whatever `dispatch` was nearest — which, for the common wrapper idiom fn dispatch(..) -> ToolOutcome { tools::dispatch(..) } is the wrapper itself. The graph gained a self-loop, the real cross-module edge never existed, and `impact` reported the callee as unreached: the issue's repository showed its central tool dispatcher as `risk: LOW` with 0 affected processes and both "callers" being `#[cfg(test)]` functions, while still labelling the result `epistemic: "exact"`. Resolve paths the way rustc does, over the module tree rather than the filesystem: - `mod_item` now emits `@declaration.namespace`, so a Rust module is a named definition rather than an anonymous scope region. This mirrors the existing C++ `namespace_definition` capture and lets the shared `tagNamespacePrefixes` pass stamp members with their enclosing module path — that pass needed no changes to start working for Rust. - `module-path.ts` reconstructs the other half of the tree: crate roots are directories holding `main.rs`/`lib.rs`, and a file's module path is its location below that root. A definition's module is its file's module plus any enclosing `mod` blocks. - `crate::`, `self::` and `super::` are prefix transforms on the calling module, not reasons to stop resolving. - The final path segment is looked up as a member of the resolved module, including members it only re-exports. A `pub use` creates no binding on the re-exporting module's own scope, so re-exports are followed through that module's import edges. Resolution runs ahead of the implicit-`this` and scope-chain tiers, so an explicit path outranks a lexical shadow, and returns undefined on an unknown module, a missing member or a tie — leaving the existing chain untouched. The new `ScopeResolver.resolveQualifiedFreeCall` hook is optional and unset for every other language, so this is additive. Fixes the reported case (direct callers 2 -> 3, impacted 2 -> 6, the Agent module now visible) plus multi-segment paths, `super::` paths and `pub use` facades, each of which previously produced a wrong edge. Known limitation, pre-existing and unchanged by this commit: an inline `mod inner { fn dispatch }` and a crate-root `fn dispatch` in the same file collapse to one graph node, because node identity is `<file>:<qualifiedName>` and does not carry the module path. That is a separate defect requiring module-path-qualified node ids and an incremental-schema migration. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * test(rust): rebaseline the scope-capture fingerprint for the module-tree captures `mod_item` now emits `@declaration.namespace` and scoped call sites carry `@reference.qualified-name`. Both are additive, so every bench fixture holding a `mod` block or a `Foo::bar()` call gains capture groups, and the corpus grew by the three `rust-2730-*` fixtures. Only the Rust fingerprint moves. The other 14 languages are byte-identical, which is the intended blast radius for a language-local capture change. Scaling stays linear at 1.043, well inside the 1.5 budget. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): carry crate identity in qualified module paths (#2741 review H1) A module was identified by its path segments below a crate root, so `crates/alpha/src/tools.rs` and `crates/beta/src/tools.rs` were the same module. A cargo workspace routinely gives several members the same internal module name — `util`, `error`, `config`, `types` are near-universal — and that made qualified resolution do one of two wrong things: - where only one member defined the called name, the call bound ACROSS crates; - where both defined it, the lookup saw two candidates, refused, and handed the site back to the lexical walk that emits the same-name self-loop. The fix for #2730 therefore switched itself off in exactly the workspace layouts it was written for, and #2730's own reported reproduction repository is multi-crate. A module is now `{ crateRoot, segments }` and `sameModule` compares both. Rust has no implicit cross-crate paths — reaching another crate requires naming it — so two modules in different crates are never the same module. Anchored paths (`crate::`, `self::`, `super::`) resolve inside the caller's own crate and inherit its root. Covered by a two-member workspace fixture where both crates define `tools::dispatch` behind a same-name wrapper, plus unit tests for the path arithmetic itself, including the branches no fixture reaches (a file under no crate root, a `super::` chain walking above the crate root). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): count only module members when resolving a qualified call (#2741 review H3) Module membership was inferred from the file path alone, so any callable in the right file counted as a member of the module. A `fn` nested inside another `fn` has the same `filePath`, the same bare `qualifiedName` and no owner, making it indistinguishable from a module-level item: pub fn dispatch() -> usize { 3 } // the real member pub fn wrapper() -> usize { fn dispatch() -> usize { 99 } // counted as a second member dispatch() } Two candidates tie, the lookup refuses, and the call falls back to the lexical walk that emits the same-name self-loop — so an unrelated local helper anywhere in a module silently reinstated #2730 for every qualified call into it. The scope model already draws the line exactly: a module-level item is bound with `origin: 'local'` in its module's own scope, a function-local item binds in the enclosing Block, and an `impl`/trait method binds in the Class scope. Membership is now that binding lookup rather than a path comparison. Inline-`mod` members bind in their Namespace scope rather than the file's Module scope, and reaching it would mean walking every child scope — faulting them back in from disk on the out-of-core path. They keep being identified by the `namespacePrefix` the shared tagging pass stamps on them, which a file-module member never carries. The documented residual is a `fn` nested inside a `fn` inside an inline `mod`, which inherits that prefix; that is strictly smaller than before and costs a refusal, never a wrong edge. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): require a use-binding to name a module, not a type (#2741 review H2) Import resolution deliberately strips a trailing symbol segment when probing for a file — "the last segment might be a symbol (function, struct, etc.), not a module. Strip it and try again" (import-resolvers/rust.ts). So `use crate::client::ClientBuilder;` also resolves to `client/mod.rs`. The qualified-call resolver took that at face value and treated the imported TYPE as the module `client`. Rust impl methods carry a bare `qualifiedName`, so `ClientBuilder::new()` was then looked up among `client`'s module members and bound to an unrelated module-level `new` — turning an unresolved site into a false edge, which the module's own contract calls the worse outcome. A binding now has to name the module it resolved to. The edge's `targetExportedName` is the tail of the written path, so comparing it against the resolved module's own tail separates the cases exactly: use crate::tools; tail `tools` module ['tools'] accept use crate:🅰️:b as tools; tail `b` module ['a','b'] accept use crate::tools::{self, Ctx}; tail `tools` module ['tools'] accept use crate::client::ClientBuilder; tail `ClientBuilder` module ['client'] reject Covered by a fixture where `client/mod.rs` deliberately holds both `impl ClientBuilder { fn new }` and a module-level `fn new`, so a regression re-binds to the wrong one, plus a control asserting a genuine `client::new()` module qualifier still resolves. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): give src/bin targets their own crate root (#2741 review) Cargo auto-discovers a binary target for every `src/bin/<name>.rs`. Each is a separate crate with its own `crate::` root, and its submodules live under `src/bin/<name>/`. Only `main.rs` and `lib.rs` established a crate root, so those entry files were folded into the surrounding library and given the invented module path `bin::<name>`. That made `crate::helper()` inside a binary resolve into the LIBRARY's `helper` — and unlike the other findings in this review, this one downgraded an edge the lexical walk had previously resolved correctly, so it made existing output worse rather than merely failing to improve it. `src/bin/<name>.rs` is now its own crate root (as is the `src/bin/<name>/main.rs` directory form), so a binary's modules and the library's modules of the same name are no longer the same module. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): only try a submodule candidate the caller actually declares (#2741 review) The first candidate module was `callerModule ++ qualifier`, yielded before the `use` channel and never checked against anything. That let file layout outrank a real import: with `use crate::b;` in `src/a/mod.rs` and an undeclared — or `cfg`-gated — `src/a/b.rs` present on disk, `b::f()` bound to the sibling file, where rustc resolves it to `crate::b`. A `mod` declaration, inline or file-backed, emits a `Namespace` def bound locally in the declaring scope, so the candidate is now gated on that binding rather than assumed. When the caller does not declare the submodule the candidate is skipped and the `use` and crate-root channels still run, so this only removes guesses. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): follow only real re-exports, and refuse on an ambiguous one (#2741 review) Two problems in the re-export channel. A private `use` was followed as though it re-exported. `use crate::tools::helper;` makes `helper` visible INSIDE the module; it does not put it on the module's public surface, so `facade::helper()` does not compile. Only `pub use` does, and finalize already distinguishes them — `reexport` for `pub use`, `named` for a private one. The `alias` kind is now accepted alongside `reexport`, because `pub use x::y as name` is a re-export that was previously ignored entirely. The lookup also took the first matching edge in file-iteration order, which is parse-pool order. Two `cfg`-exclusive facades re-exporting the same name are indistinguishable at this layer, so picking one baked a coin flip into the graph. It now refuses on a genuine tie, consistent with how member lookup already behaves. The pre-existing limitation that only FILE modules are reachable — a `pub use` inside an inline `mod facade { … }` has no `moduleScopeByFile` entry — is now stated in the code. Reaching those would mean walking every child scope and faulting the scope tree back in from disk, which is the cost that index exists to avoid; a miss falls through to the unchanged chain rather than guessing. The regression test deliberately makes the re-exported name globally ambiguous. Without that, the pre-existing unique-global free-call fallback resolves the call on its own and the assertion passes whatever this channel does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * perf(rust): stop type-qualified calls paying for module resolution (#2741 review) The capture carrying `rawQualifiedName` matches every `scoped_identifier` callee, so this hook was reached by `Vec::new()`, `String::from()`, `Self::method()` and every other type-qualified call — the overwhelming majority of `::` calls in real Rust, none of which name a module. Each one ran the full candidate search before returning undefined, and every candidate that missed then walked all of `workspaceIndex.moduleScopeByFile`. Total cost grew as `qualified-call-sites x files`; two independent measurements put per-site cost at 0.117 -> 0.428 ms across 301 -> 1201 files, i.e. linear in workspace size. Two changes: - The module index now carries a flat set of every module segment name in the workspace, and a qualifier whose head matches none of them is rejected before any candidate work. Measured at 0.02 us per rejected call and flat in file count (500 -> 8000 files), against a previously linear per-site cost. - Module scopes are indexed by module identity once per pass rather than rediscovered by scanning every file per candidate. On the out-of-core scope index that scan was worse than CPU: `moduleScopeByFile` fetches through `scopeTree.getScope`, so a full sweep could fault every module scope back in from disk — the pattern `workspace-index.ts` added `exportedCallableByName` to avoid. Given the #2649 and #1871 history this mattered before merge. The captures golden is regenerated for the fixture files added earlier in this series; `emitRustScopeCaptures` itself is unchanged by this commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(storage): bump schema versions so the #2730 fix reaches existing indexes Neither invalidation constant was bumped, so the fix did not reach the users who reported the bug. `INCREMENTAL_SCHEMA_VERSION` 22 -> 23. The incremental write set only covers CHANGED files, so a top-up against a pre-v23 index keeps the wrong self-loop — and keeps reporting the callee as unreached — for every unchanged Rust file. The constant's own doc block states this rule, and the precedent is exact: v11 is the same file (`rust/query.ts`) gaining a capture that changes CALLS edges, with the same "force a full re-analyze" contract, and v12 is a second Rust instance. `SCHEMA_BUMP` 30 -> 31. `@declaration.namespace` and `@reference.qualified-name` are parse-time captures, so a warm parse cache replays the old capture set verbatim: `rawQualifiedName` comes back undefined and no Namespace def exists to hang a module prefix on, turning the entire resolution tier into a no-op on unchanged files. `PARSE_CACHE_VERSION` folds in the package version, so a tagged release would have invalidated eventually — but source, dev and CI builds at the same version would not, and the v29 note already warns that relying on someone else's bump is how a change ships with no invalidation at all. Re-checked against origin/main at commit time, as that note instructs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(scope-resolution): let a language opt out of the already-namespaced guard (#2741 review) `tagNamespacePrefixes` skips a def whose `qualifiedName` already equals, or is prefixed by, its enclosing namespace path. That is right for C++ and C#, where the qualified name genuinely carries the namespace. Rust qualified names never do, so the guard fired on a coincidence: in `mod a { pub fn a() }` the member's name equals its module's name, the prefix was skipped, and `moduleOfDef` then reported the member as belonging to the PARENT module. `crate:🅰️:a()` refused, and the def became indistinguishable from a crate-root `fn a` for the module matcher. The guard is now conditional on a `qualifiedNamesCarryNamespace` option that defaults to the existing behaviour, and Rust opts out. The shared pass stays language-neutral — the decision lives with the provider that knows what its own qualified names contain. C++ and C# resolver suites pass unchanged alongside the Rust ones (600 tests). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * fix(rust): refuse a leading :: path instead of reading it as relative (#2741 review) A leading `::` anchors at the extern prelude: `::tools::dispatch()` names the CRATE `tools`, not a module of the current one. The path split filtered the empty leading segment away, which silently reinterpreted the path as relative and let it resolve against a local module that happens to share the name. Extern crates are outside the workspace module tree, so the qualified tier now refuses and leaves the site to the unchanged chain. The regression test asserts the tier does not bind into the local `tools` module, rather than asserting no edge at all: the lexical tier still resolves the bare tail on its own, and that behaviour is not what this change governs. Asserting an empty edge list would have been testing a different tier. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * refactor(rust): reuse the canonical callable predicate and drop dead re-exports (#2741 review) `CALLABLE_TYPES` was a local copy of the set behind `isOverloadableCallable` in `utils/callable-labels.ts`. Two copies of the same set drift: extending the canonical one with a new callable kind would silently leave qualified calls of that kind unresolved here, with nothing to catch it. Use the shared predicate. The trailing `export { moduleOfFile, moduleOfDef }` and `export type { ScopeResolutionIndexes }` were commented as being "for the resolver's unit tests". No test imports them: the only importer of this module anywhere in src or test is `rust/scope-resolver.ts`, which takes just `resolveRustQualifiedFreeCall`. Both functions are already exported from `module-path.ts` (where the new unit tests take them from), and `ScopeResolutionIndexes` is canonically exported from `model/scope-resolution-indexes.ts`. Removed rather than left as surface that implies a contract it does not have. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * test(rust): rebaseline the scope-capture fingerprint with the correct prior hash The rebaseline note added with the original fix cited `Prior 655aed01…`, which was two rebaselines stale — it predates both #2604 and #2714. The true pre-PR value on the base commit is `7f1240b3…`. CI could not catch it: the gate compares the live fingerprint against the stored one and never reads the prose, so the audit chain these notes exist to provide was broken with nothing to flag it. The note now carries the correct prior value, and the fingerprint is regenerated for the fixtures this review series added. Scaling 1.061, well inside the 1.5 budget; fixture_count 196; the other 14 languages remain byte-identical. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV * test: move the schema-version pin to 23 `call-summary-schema-version.test.ts` asserts the exact value of `INCREMENTAL_SCHEMA_VERSION` and enumerates which stamped versions the incremental reuse gate accepts. It moves with every bump by design — that pin is what stops an id- or edge-changing commit shipping without invalidation. Updated for the bump to 23, with the pre-v23 case added to the reuse-gate table: a v22 index predates Rust module-qualified call resolution, so every unchanged Rust file would keep the same-name self-loop and keep reporting the real callee as unreached. Caught by CI rather than locally, because the earlier sweeps in this series covered `test/integration/resolvers/` and `test/unit/scope-resolution/` only — the pin lives outside both. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J5nWP4BFeBSjbQ3uqAjtxV --------- Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 13:41:47 +01:00
Gergo Magyar	9f57984372	style: fix quote style per prettier in new dyn-normalization test	2026-07-21 16:12:20 +00:00
Gergo Magyar	e18b4416c6	test(rust): cover Box<dyn Trait> and dyn-bound-list normalization (#2604) ... GitNexus review-agent finding: stripDynBound's documented Box<dyn Trait>, Rc/Arc<dyn Trait>, and auto-trait/lifetime bound-list (dyn Trait + Send) shapes had no test anywhere — only the bare &dyn Trait parameter case was exercised end-to-end. Add direct unit coverage on normalizeRustTypeName and (via interpretRustTypeBinding) normalizeRustReturnType for these shapes.	2026-07-21 16:10:01 +00:00
Gergo Magyar	6b013e7d30	fix(scan): lock in Rust publish order and guard PHP suffix roots ... Adds the missing #2481 Rust regression test (importer before definer), fails closed when a PHP namespace suffix matches directories under different roots, and points the baselines note at #2481/#2482. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 08:42:07 +00:00
Gergő Magyar	d1d2a64d0f	perf(ingestion): linearize scope-capture across all languages + Python import resolution (O(n²)→O(n)) (#1918) ... * bench(python-scope): build-free measure harness + baseline fingerprint for emitPythonScopeCaptures ce-optimize scaffolding for the python-scope-capture run. Mirrors the Go scope-capture harness (#1848): imports the .ts hotpath via tsx, times emitPythonScopeCaptures on a synthetic DAO source at 250/800 entities, and pins an order-independent sha256 capture fingerprint over the whole lang-resolution/python-* corpus + a fixed 20-entity DAO as the correctness gate. Baseline (current code) is O(n^2): 250->800 entities (3.2x) -> 10.7x time (1062->11343ms), scaling_ratio 3.34. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * optimize(python-scope-capture): thread captured nodes to kill O(n^2) findNodeAtRange re-walks emitPythonScopeCaptures re-derived each tree-sitter match's AST node via findNodeAtRange(tree.rootNode, ...) on every match, scanning all of root's named children per call -> O(matches x rootChildren) ~ O(n^2). The same #1848 bug Go had (fixed in eaf0a305), mirrored in Python's captures.ts. Thread the query-captured SyntaxNode (c.node) through a parallel tag->node map and use it directly for all three sites (import / @scope.function / @declaration.function). The Python scope query captures the full statement/definition node, so the captured node IS the one the old code re-derived by range — no ancestor walk needed (simpler than Go's import case). Output is byte-identical: an order-independent sha256 capture fingerprint over all 188 lang-resolution/python-* fixtures + a 20-entity DAO is unchanged. 800 entities: 11343ms -> 319ms (35.5x); 250: 1063ms -> 95ms (11.2x); scaling_ratio 3.34 -> 1.05 (quadratic -> linear). tsc clean; 291 python scope-resolution + resolver tests pass. Adds a golden capture-parity test (forward-drift guard across the python-* corpus + DAO shape) and a non-gated O(n^2) regression tripwire (400-entity source, 346ms vs a 10s budget). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * optimize(python-scope-capture): index Python import resolution to kill O(imports x files) scans resolvePythonImportTarget's fallback path scanned the entire repo file set on every unresolved/external dotted import — once in hasRepoCandidate (package gate) and once in resolveAbsoluteFromFiles (suffix match) — giving O(imports x files) ~ O(n^2) in the resolution phase (audit follow-up to the capture-phase #1848 mirror). Add a per-file-set index (byBasename buckets + .py dir-prefix set + normalized path set), memoized on the allFilePaths Set via a WeakMap so it is built once per run and reused across every import. The two O(files) scans become O(1)/O(bucket) lookups. The shared buildSuffixIndex is deliberately NOT reused: it keeps only a single path per suffix (longest wins) and cannot reproduce Python's exact fewest-segments-then-lexicographic tie-break across all candidates (see the import-target.ts:72 rationale) — so a purpose-built index is used instead. Output is identical: a resolver-output fingerprint over 10,021 cases (exhaustive branch matrix — tie-breaks, gating, collisions, windows paths — plus a 400-repo deterministic fuzz) is byte-for-byte unchanged (e6ec1a59...). Worst-case scaling (k imports x k files): 500/1000/2000/4000 went 25/62/231/899ms -> 1.2/2.9/6.7/10.7ms (84x at 4000, quadratic -> linear). tsc clean; 303 python scope-resolution + resolver tests pass; adds a 10-case parity guard pinning the tie-break / gating / collision semantics the index must preserve. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(python): land the import-index reuse on the registry-primary path (PR #1918 P1) The PythonFileIndex WeakMap is keyed on allFilePaths Set identity, but pythonScopeResolver.resolveImportTarget wrapped the orchestrator's stable run-level set in `new Set(allFilePaths)` per import, handing a fresh key to every import — so the index rebuilt on every import and the O(imports x files) cost this index removed persisted on the production path (PR #1918 review P1). Thread ReadonlySet<string> through the resolver chain (PythonResolveContext, getPythonFileIndex, the WeakMap key, resolveAbsoluteFromFiles, hasRepoCandidate, resolvePythonImportInternal, tryResolveWithExtensions — all read-only) and drop the per-import copy so the stable set reaches the WeakMap key. Mirrors the C# counterpart (csharp/import-target.ts), which already keys on ReadonlySet. Guard it deterministically: an ungated index-build counter (index-stats.ts) + a production-path integration test that drives pythonScopeResolver over 300 imports on a stable set and asserts the index is built ONCE (was 300 pre-fix). tsc clean; resolver-output fingerprint unchanged (e6ec1a59); 369 python scope-resolution + resolver tests pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * perf(python): index only .py files in the import-resolution index (PR #1918 P3b) getPythonFileIndex pushed every workspace file into byBasename (and normSet), but Python import resolution only ever queries .py paths — module <seg>.py, package <seg>/__init__.py, and .py directory prefixes. Non-.py files (.ts, .go, …) could never match any lookup, so they were pure dead weight in the index on polyglot monorepos. Skip non-.py files at the top of the index builder. dirPrefixes was already .py-gated; this extends the same guard to byBasename and normSet (both also .py-only consumers), so it is behavior-preserving. Resolver fingerprint unchanged (e6ec1a59); adds a polyglot parity case proving .ts/.go siblings never affect resolution. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * perf(python): parent-key the __init__ bucket to kill package-count skew (PR #1918 P2b) The suffix fallback's package form looked up byBasename.get('__init__.py'), which holds every __init__.py in the repo — so every multi-segment package import (pkg.sub) iterated all N packages to find the one ending /sub/__init__.py. Add byInitParent: __init__.py files keyed by their last two components (<parentDir>/__init__.py). The package lookup now targets only same-named package dirs (typically O(1)) and confirms the full suffix, so the final candidate set and tie-break are unchanged. __init__.py files stay in byBasename too, so the rarer explicit "pkg.__init__" import still resolves via the module (<lastSeg>.py) lookup. Resolver fingerprint unchanged (e6ec1a59); adds parity cases for a nested package (same-parent noise filtered by the suffix confirm) and an explicit pkg.__init__ import. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(python): reproduce old startsWith gating for absolute paths + re-baseline (PR #1918 P3a) getPythonFileIndex built dirPrefixes by split('/')+filter(Boolean), which drops the leading empty component of an absolute path: "/repo/svc/x.py" yielded {repo/, repo/svc/}. The old full-scan gate compared the whole normalized path, where "/repo/svc/x.py".startsWith("repo/svc/") is false — so the index gate PASSED where the old gate BLOCKED, an absolute-path-only divergence (production paths are repo-relative, so this never fired in production). Build dirPrefixes from every slash-terminated prefix of the full path instead (including the leading "/" for absolute paths), so dirPrefixes.has(X) matches exactly when the old f.startsWith(X) did. For repo-relative paths the prefix set is identical, so production behavior is unchanged. This is NOT cosmetic. Extending the fingerprint harness with absolute-path file sets surfaced 12 fuzz cases (out of ~4000 new absolute cases) where the pre-fix index resolved an import the old code left unresolved — e.g. `pkg.thing` over {/repo/pkg/__init__.py, /repo/vendor/pkg/thing.py} from /repo/app/main.py resolved to /repo/vendor/pkg/thing.py under the buggy gate but is null (old and fixed). The fix removes those absolute-path false positives. Re-baseline justification: the committed resolver fingerprint moves e6ec1a59 -> d51ea9ed because the harness now adds ~4000 absolute-path cases (branch matrix incl. the reviewer's exact case + a 200-repo absolute fuzz). The relative-path subset is unchanged: the original 10,021-case relative corpus still hashes to e6ec1a59 after the dirPrefixes fix (the fix only alters absolute-path prefixes). The new baseline encodes the old-startsWith-equivalent (correct) behavior, verified by diffing the fixed vs. pre-fix harness output. Adds parity cases pinning the absolute false-positive (now null) and a repo-relative control of the same shape (still resolves). tsc clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(python-bench): add --check mode + REPS=7 to the scope-capture harnesses (PR #1918 P2a) The bench harnesses were dev-only — nothing compared the committed fingerprints or guarded the scaling, so an O(n^2) regression (or a P1-style cache miss) could land silently. Add a --check mode to both: - measure.mjs: assert the capture fingerprint == baseline-fingerprint.txt AND scaling_ratio < 1.5 (linear), exit non-zero on either. REPS bumped 3 -> 7 to stabilize the median on shared CI runners. - import-target-fingerprint.mjs: assert the resolver fingerprint == baseline-import-target-fingerprint.txt, exit non-zero on drift. Without --check both still print JSON for dev use / deliberate re-baselining. Verified: --check passes on the current tree (capture f2b4376f / scaling 1.04; resolver d51ea9ed) and exits 1 with a clear message on a corrupted baseline. Wired into CI by the dedicated benchmark job (next commit). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci(bench): add a dedicated benchmark job wiring in the gated cross-language suites The cobol/csharp/rust/php/ruby *-pipeline-benchmark.test.ts suites are gated behind GITNEXUS_BENCH, so the main coverage job skips them — their O(n^2) scaling guards never actually ran in CI. Add a dedicated "benchmarks" job to the Tests reusable workflow that runs them with GITNEXUS_BENCH=1, plus the Python scope-capture and import-resolution fingerprint + scaling guards (measure.mjs --check, import-target-fingerprint.mjs --check) from PR #1918. Runs with --no-file-parallelism: the suites measure wall-clock and peak heap, so parallel forks both skew the timings and OOM the worker pool (reproduced locally: the parallel run crashes a worker; serial passes 5/5 in ~80s). The job is part of the Tests workflow, so it gates the existing CI Gate required check. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci(bench): exclude go-pipeline-benchmark from the gated job (fork-pool instability) Validation surfaced that go-pipeline-benchmark.test.ts's worker-pool (#1848) suite spins a real worker pool that exits unexpectedly under vitest's fork pool, crashing the run (1 of 3 tests, repeated). Including it would make the new benchmark gate flaky. The other five language pipeline benchmarks (cobol/csharp/rust/php/ruby) run clean serially (5/5, ~84s). Go is already guarded by its non-gated O(n^2) tripwire (main coverage job) + golden parity test, so coverage is preserved. Documented inline. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci(security): set persist-credentials false on all ci-tests checkouts (zizmor artipacked) The new benchmarks job (and the pre-existing tests / cross-platform jobs) used actions/checkout with the default persist-credentials, leaving the token in .git/config. The tests job uploads a test-reports artifact, so that is the literal credential-persistence-through-artifacts case zizmor's artipacked audit flags; the others persist creds needlessly. None of these jobs push — they run npm + vitest only — so persist-credentials: false is safe (the packaged-install-smoke job already runs setup-gitnexus this way). All four ci-tests.yml checkouts are now consistent. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * bench(scope-capture): unified build-free measure harness for all benchmarked languages Adds a single tsx harness that measures emit<Lang>ScopeCaptures for every language with a pipeline benchmark (go, csharp, rust, php, ruby, cobol): per-language synthetic-DAO scaling (250/800 entities) + an order-independent sha256 fingerprint over each <lang>-* fixture corpus, with a --check mode gating both against baselines.json. It immediately surfaced that csharp, rust, php and ruby still carry the O(matches x rootChildren) findNodeAtRange(tree.rootNode,...) root-walk that was fixed for go (#1915) and python (#1918): scaling ratios 3.13 / 3.31 / 3.04 / 3.07 (vs ~1.0 for the fixed go and cobol). They are flagged known_quadratic in baselines.json so CI guards drift + worsening until each gets the threaded-node fix (following commits). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * perf(ruby): linearize scope-capture (thread captured nodes + dedup set) emitRubyScopeCaptures re-derived each match's node via findNodeAtRange(tree. rootNode,...) per match (import / scope.function / declaration.function / heritage / attr / call-arity), and the constructor-return pass ran out.some(...) once per method over the growing output array — two O(n^2) shapes (measured scaling 3.07). Thread the query's captured node (c.node) through a nodeMap and resolve each anchor with a type-guarded lookup (nodeIfType), and precompute the YARD-return dedup keys into a Set. Output byte-identical (capture fingerprint over the ruby-* fixture corpus + DAO unchanged); scaling 3.07 -> 1.11 (linear). 127 ruby resolver tests pass; tsc clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * perf(php): linearize scope-capture (thread captured nodes) emitPhpScopeCaptures re-derived each match's node via findNodeAtRange(tree. rootNode,...) per match (import / scope.function / declaration / call-arity), giving O(matches x rootChildren) ~ O(n^2) (measured scaling 3.04). Thread the query's captured node (c.node) through a nodeMap and resolve each anchor with a type-guarded lookup (nodeIfType), mirroring go #1915 / python #1918. Output byte-identical (capture fingerprint over the php-* fixture corpus + DAO unchanged); scaling 3.04 -> 1.03 (linear). 205 php resolver tests pass; tsc clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * perf(rust): linearize scope-capture (thread captured nodes) emitRustScopeCaptures re-derived each match's node via findNodeAtRange(tree. rootNode,...) per match (import / scope.function / declaration / type-binding return-hoist / call-arity), giving O(matches x rootChildren) ~ O(n^2) (measured scaling 3.31 — the worst of the four). Thread the query's captured node (c.node) through a nodeMap and resolve each anchor with a type-guarded lookup (nodeIfType), mirroring go #1915 / python #1918. Output byte-identical (capture fingerprint over the rust-* fixture corpus + DAO unchanged, incl. the impl-block return-type hoist path); scaling 3.31 -> 1.05 (linear). Rust resolver tests pass; tsc clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * perf(csharp): linearize scope-capture (thread captured nodes) emitCsharpScopeCaptures re-derived each match's node via findNodeAtRange(tree. rootNode,...) per match at 7 sites (import / read.member / scope.function / declaration / call-arity / primary-constructor class+record), giving O(matches x rootChildren) ~ O(n^2) (measured scaling 3.13). Thread the query's captured node (c.node) through a nodeMap and resolve each anchor with a type-guarded lookup (nodeIfType), mirroring go #1915 / python #1918. Output byte-identical (capture fingerprint over the csharp-* fixture corpus + DAO unchanged); scaling 3.13 -> 0.99 (linear). C# resolver tests pass; tsc clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci(bench): tighten scope-capture budgets to linear + gate all 6 languages in CI All six benchmarked languages now thread the captured node, so update baselines.json: drop known_quadratic and set scaling_budget 1.5 (linear) for csharp/rust/php/ruby (go/cobol already linear). Fingerprints are unchanged — every fix was byte-identical. Wire the unified build-free guard into the benchmarks job: 'node --import tsx bench/scope-capture/measure.mjs --check' asserts the capture fingerprint and linear scaling for go/csharp/rust/php/ruby/cobol on every run. Build-free (no worker pool), so unlike the go pipeline benchmark it is stable in CI. measure --check passes locally for all six (scaling 0.86-1.10). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * refactor(ingestion): address PR #1918 tri-review — shared nodeIfType, duck-typed guard, docs Tri-review follow-ups (no behavior change — all capture fingerprints + the resolver fingerprint are byte-identical, verified via the bench --check gates): - maintainability (M1): extract the `nodeIfType` helper (copy-pasted into 4 captures.ts files) to ast-helpers.ts as a generic `nodeIfType<T extends SyntaxNode>`. csharp/php keep their local SyntaxNode aliases (used elsewhere); the generic signature accepts them. - P2 (latent): duck-type the `resolvePythonImportTarget` shape-guard instead of `instanceof Set`. The context type was widened to ReadonlySet<string>; an `instanceof Set` check would reject a legitimate non-Set ReadonlySet and silently drop all Python import edges. Now checks `.has` + `[Symbol.iterator]`. - P3 (ruby dedup): document the snapshot-vs-live `out.some`→Set behavior — the one narrow corner (two same-named methods one row apart, both ending in Const.new) where output differs from the pre-PR code, and why the new behavior (emit both) is intended. - harness cross-ref: note in python-scope/measure.mjs that Python's capture scaling is guarded there (not the unified scope-capture harness) so neither is removed assuming the other covers Python. tsc clean; scope-capture --check passes (6 languages, unchanged + linear); resolver fingerprint unchanged; 300 python/ruby/rust tests pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(ingestion): golden + O(n^2) tripwire tests for ruby/rust/php/csharp scope-capture Addresses the PR #1918 tri-review test-gap consensus (testing + adversarial + maintainability): the four newly-linearized languages had no committed correctness/scaling lock in the standard unit-test job — only the bench/scope-capture/measure.mjs --check fingerprint, which runs in the separate benchmarks CI job. Per language, mirroring the existing go/python tests: - test/unit/scope-resolution/<lang>/<lang>-captures-golden.test.ts — ORDER- SENSITIVE golden (modeled on go-captures-golden.test.ts; catches emission reordering the order-independent bench fingerprint misses) over the whole lang-resolution/<lang>-* corpus + a 20-entity synthetic DAO, with UPDATE_GOLDEN regeneration. Runs in the normal unit-test job (fast-fail). - test/integration/<lang>-scope-capture-tripwire.test.ts — non-gated O(n^2) regression tripwire (400-entity source, <10s budget), like python's. The ruby golden also pins the snapshot-dedup behavior (two same-named methods both ending in Const.new emit BOTH @type-binding.return bindings — PR #1918 P3), and the rust golden exercises the impl-block return-type hoist path. 41 tests pass; tsc clean. Goldens generated against the (byte-identical) current output. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-05-30 19:44:22 +01:00