gitnexus 1.6.10-rc.21 → 1.6.10-rc.211

package/dist/core/ingestion/languages/rust/module-path.d.ts

@@ -0,0 +1,126 @@
+/**
+ * Rust module paths — the module tree, expressed over the scope model.
+ *
+ * rustc resolves `a::b::dispatch` against a MODULE TREE, not a file tree: `mod`
+ * is an item with its own `DefId`, and a path's leading segments name modules in
+ * the *type* namespace (which is why a same-named `fn` can never shadow them —
+ * functions live in the value namespace). GitNexus models the same tree in two
+ * halves, and this module joins them:
+ *
+ *   - **Inline modules** (`mod inner { … }`) are `Namespace` scopes owning a
+ *     `Namespace` def, so the shared `tagNamespacePrefixes` pass stamps members
+ *     with `namespacePrefix = 'inner'` / `'outer.inner'`.
+ *   - **File modules** (`mod tools;` loading `tools.rs` or `tools/mod.rs`) leave
+ *     no in-file marker at all — the module path lives in the FILE PATH relative
+ *     to the crate root. That half is reconstructed here.
+ *
+ * ## Module identity carries its crate
+ *
+ * A module is `{ crateRoot, segments }`, never bare segments. A cargo workspace
+ * routinely gives several members the same internal module name — `util`,
+ * `error`, `config`, `types` are near-universal — and identity by segments alone
+ * makes `crates/a/src/tools.rs` and `crates/b/src/tools.rs` the same module. That
+ * mis-binds a call across crates when only one defines the member, and (worse)
+ * ties the lookup when both do, so qualified resolution refuses and the call
+ * falls back to the lexical walk that #2730 exists to prevent. Rust has no
+ * implicit cross-crate paths: reaching another crate requires naming it, so two
+ * modules in different crates are never the same module.
+ *
+ * Everything here is pure path arithmetic over the workspace file set; no I/O.
+ */
+/**
+ * A module's full identity: the crate it belongs to, plus its `::`-path inside
+ * that crate. `segments` is empty for the crate-root module itself.
+ */
+export interface RustModule {
+    /** Crate-root directory (`src`, `crates/noob/src`, or `''` at repo root). */
+    readonly crateRoot: string;
+    readonly segments: readonly string[];
+}
+export interface RustModuleIndex {
+    /** Crate-root directories, longest first, so nested crates win. */
+    readonly crateRoots: readonly string[];
+    /**
+     * Every module name derivable from a FILE PATH, as a flat set of single
+     * segments. Inline `mod x { … }` names are absent by construction — they exist
+     * in no path — so this is only half of the negative filter's input; the
+     * resolver unions it with the inline module names it collects from the scope
+     * model (#2742).
+     */
+    readonly moduleNames: ReadonlySet<string>;
+    /**
+     * Entry files that are a crate root in their own right rather than a module of
+     * the surrounding crate — `src/bin/<name>.rs` auto-discovered binary targets.
+     * Maps the entry file to the directory its own submodules live under.
+     */
+    readonly standaloneRootFiles: ReadonlyMap<string, string>;
+}
+/**
+ * Index the workspace's crate roots: every directory holding a `main.rs` or
+ * `lib.rs`. A cargo workspace has one per member (`crates/noob/src`), a plain
+ * package exactly one (`src`). Longest-first ordering makes `moduleOfFile` pick
+ * the innermost enclosing crate for nested layouts.
+ *
+ * Cargo also auto-discovers a binary target per `src/bin/<name>.rs`. Each is a
+ * separate crate with its own `crate::` root, and its submodules live under
+ * `src/bin/<name>/`. Treating those files as ordinary modules of the library
+ * invented the module path `bin::<name>`, which made `crate::helper()` inside a
+ * binary resolve into the LIBRARY — downgrading an edge the lexical walk had
+ * previously got right (#2741 review).
+ */
+export declare function buildRustModuleIndex(allFilePaths: ReadonlySet<string>): RustModuleIndex;
+/**
+ * Could this qualifier name a module that exists in the workspace?
+ *
+ * A negative answer is authoritative and cheap: if the head segment matches no
+ * module name anywhere, no candidate channel can resolve it. Anchors keep their
+ * meaning (`crate::`/`self::`/`super::` are relative to the caller, so the head
+ * to test is the first non-anchor segment); an all-anchor qualifier (`self::f()`)
+ * names the caller's own module and is always worth trying.
+ */
+export declare function couldNameAModule(qualifier: readonly string[], knownModuleNames: ReadonlySet<string>): boolean;
+/**
+ * Module identity of the file itself: its crate root plus the `::`-segments
+ * below it.
+ *
+ *   src/main.rs                     → { src,             [] }   (crate root module)
+ *   src/tools.rs                    → { src,             ['tools'] }
+ *   src/a/mod.rs                    → { src,             ['a'] }
+ *   src/a/b.rs                      → { src,             ['a', 'b'] }
+ *   crates/noob/src/tools/mod.rs    → { crates/noob/src, ['tools'] }
+ *
+ * Returns `undefined` for a file under no known crate root — the caller then has
+ * no module identity to reason about and must refuse rather than guess.
+ */
+export declare function moduleOfFile(filePath: string, index: RustModuleIndex): RustModule | undefined;
+/** Full module identity of a definition: its file's module plus any `mod` blocks around it. */
+export declare function moduleOfDef(filePath: string, namespacePrefix: string | undefined, index: RustModuleIndex): RustModule | undefined;
+/**
+ * Resolve a written path's leading segments to a module, from the calling
+ * module. Mirrors rustc's anchor handling:
+ *
+ *   crate::a::b   → the caller's OWN crate, segments ['a','b']
+ *   self::a       → callerModule ++ ['a']
+ *   super::a      → callerModule[:-1] ++ ['a']
+ *   a::b          → relative; the caller resolves this against the candidate
+ *                   channels (child module, `use` binding), so it is returned
+ *                   as-is for the caller to try in context.
+ *
+ * An anchored path always stays inside the caller's crate — `crate::` names the
+ * current crate, and `super::`/`self::` are relative to it — so the resolved
+ * module inherits `callerModule.crateRoot`.
+ *
+ * `super` chains (`super::super::x`) are consumed left to right. Returns
+ * `undefined` when the chain walks above the crate root — an invalid path that
+ * must not silently resolve to something else.
+ */
+export declare function resolveAnchoredModulePath(qualifier: readonly string[], callerModule: RustModule): {
+    readonly module: RustModule;
+    readonly anchored: boolean;
+} | undefined;
+/**
+ * Identity comparison for two modules. The crate root participates: two modules
+ * with the same internal path in DIFFERENT crates are different modules, and
+ * conflating them is what let a workspace mis-bind or refuse (#2730 review H1).
+ */
+export declare function sameModule(a: RustModule, b: RustModule): boolean;

package/dist/core/ingestion/languages/rust/module-path.js

@@ -0,0 +1,214 @@
+/**
+ * Rust module paths — the module tree, expressed over the scope model.
+ *
+ * rustc resolves `a::b::dispatch` against a MODULE TREE, not a file tree: `mod`
+ * is an item with its own `DefId`, and a path's leading segments name modules in
+ * the *type* namespace (which is why a same-named `fn` can never shadow them —
+ * functions live in the value namespace). GitNexus models the same tree in two
+ * halves, and this module joins them:
+ *
+ *   - **Inline modules** (`mod inner { … }`) are `Namespace` scopes owning a
+ *     `Namespace` def, so the shared `tagNamespacePrefixes` pass stamps members
+ *     with `namespacePrefix = 'inner'` / `'outer.inner'`.
+ *   - **File modules** (`mod tools;` loading `tools.rs` or `tools/mod.rs`) leave
+ *     no in-file marker at all — the module path lives in the FILE PATH relative
+ *     to the crate root. That half is reconstructed here.
+ *
+ * ## Module identity carries its crate
+ *
+ * A module is `{ crateRoot, segments }`, never bare segments. A cargo workspace
+ * routinely gives several members the same internal module name — `util`,
+ * `error`, `config`, `types` are near-universal — and identity by segments alone
+ * makes `crates/a/src/tools.rs` and `crates/b/src/tools.rs` the same module. That
+ * mis-binds a call across crates when only one defines the member, and (worse)
+ * ties the lookup when both do, so qualified resolution refuses and the call
+ * falls back to the lexical walk that #2730 exists to prevent. Rust has no
+ * implicit cross-crate paths: reaching another crate requires naming it, so two
+ * modules in different crates are never the same module.
+ *
+ * Everything here is pure path arithmetic over the workspace file set; no I/O.
+ */
+/** Files that make their directory a crate root (`crate::` anchors here). */
+const CRATE_ROOT_FILES = new Set(['main.rs', 'lib.rs']);
+/** A module file whose name does NOT contribute a path segment. */
+const MODULE_DIR_FILE = 'mod.rs';
+/**
+ * Index the workspace's crate roots: every directory holding a `main.rs` or
+ * `lib.rs`. A cargo workspace has one per member (`crates/noob/src`), a plain
+ * package exactly one (`src`). Longest-first ordering makes `moduleOfFile` pick
+ * the innermost enclosing crate for nested layouts.
+ *
+ * Cargo also auto-discovers a binary target per `src/bin/<name>.rs`. Each is a
+ * separate crate with its own `crate::` root, and its submodules live under
+ * `src/bin/<name>/`. Treating those files as ordinary modules of the library
+ * invented the module path `bin::<name>`, which made `crate::helper()` inside a
+ * binary resolve into the LIBRARY — downgrading an edge the lexical walk had
+ * previously got right (#2741 review).
+ */
+export function buildRustModuleIndex(allFilePaths) {
+    const roots = new Set();
+    for (const filePath of allFilePaths) {
+        const slash = filePath.lastIndexOf('/');
+        const base = slash === -1 ? filePath : filePath.slice(slash + 1);
+        if (!CRATE_ROOT_FILES.has(base))
+            continue;
+        roots.add(slash === -1 ? '' : filePath.slice(0, slash));
+    }
+    // Auto-discovered binary targets: `<crateRoot>/bin/<name>.rs`, and the
+    // directory form `<crateRoot>/bin/<name>/main.rs` (already a root above).
+    const standaloneRootFiles = new Map();
+    for (const filePath of allFilePaths) {
+        if (!filePath.endsWith('.rs'))
+            continue;
+        const slash = filePath.lastIndexOf('/');
+        if (slash === -1)
+            continue;
+        const dir = filePath.slice(0, slash);
+        if (!dir.endsWith('/bin'))
+            continue;
+        const parent = dir.slice(0, -'/bin'.length);
+        if (!roots.has(parent))
+            continue;
+        const own = filePath.slice(0, -'.rs'.length);
+        standaloneRootFiles.set(filePath, own);
+        roots.add(own);
+    }
+    const crateRoots = [...roots].sort((a, b) => b.length - a.length);
+    // Flat set of every module segment name in the workspace, for the negative
+    // filter. Built from the same single pass over file paths.
+    const moduleNames = new Set();
+    const index = { crateRoots, standaloneRootFiles, moduleNames: new Set() };
+    for (const filePath of allFilePaths) {
+        const module = moduleOfFile(filePath, index);
+        if (module === undefined)
+            continue;
+        for (const segment of module.segments)
+            moduleNames.add(segment);
+    }
+    return { crateRoots, standaloneRootFiles, moduleNames };
+}
+/**
+ * Could this qualifier name a module that exists in the workspace?
+ *
+ * A negative answer is authoritative and cheap: if the head segment matches no
+ * module name anywhere, no candidate channel can resolve it. Anchors keep their
+ * meaning (`crate::`/`self::`/`super::` are relative to the caller, so the head
+ * to test is the first non-anchor segment); an all-anchor qualifier (`self::f()`)
+ * names the caller's own module and is always worth trying.
+ */
+export function couldNameAModule(qualifier, knownModuleNames) {
+    for (const segment of qualifier) {
+        if (segment === 'crate' || segment === '$crate' || segment === 'self' || segment === 'super') {
+            continue;
+        }
+        return knownModuleNames.has(segment);
+    }
+    return true;
+}
+/**
+ * Module identity of the file itself: its crate root plus the `::`-segments
+ * below it.
+ *
+ *   src/main.rs                     → { src,             [] }   (crate root module)
+ *   src/tools.rs                    → { src,             ['tools'] }
+ *   src/a/mod.rs                    → { src,             ['a'] }
+ *   src/a/b.rs                      → { src,             ['a', 'b'] }
+ *   crates/noob/src/tools/mod.rs    → { crates/noob/src, ['tools'] }
+ *
+ * Returns `undefined` for a file under no known crate root — the caller then has
+ * no module identity to reason about and must refuse rather than guess.
+ */
+export function moduleOfFile(filePath, index) {
+    // A `src/bin/<name>.rs` entry file is its own crate root, not a module of the
+    // surrounding library.
+    const standalone = index.standaloneRootFiles.get(filePath);
+    if (standalone !== undefined)
+        return { crateRoot: standalone, segments: [] };
+    for (const crateRoot of index.crateRoots) {
+        const prefix = crateRoot === '' ? '' : `${crateRoot}/`;
+        if (crateRoot !== '' && !filePath.startsWith(prefix))
+            continue;
+        const rel = filePath.slice(prefix.length);
+        if (!rel.includes('/') && CRATE_ROOT_FILES.has(rel))
+            return { crateRoot, segments: [] };
+        const segments = rel.split('/');
+        const last = segments.pop();
+        if (last === undefined)
+            return undefined;
+        if (last !== MODULE_DIR_FILE) {
+            if (!last.endsWith('.rs'))
+                return undefined;
+            segments.push(last.slice(0, -'.rs'.length));
+        }
+        return { crateRoot, segments };
+    }
+    return undefined;
+}
+/** Full module identity of a definition: its file's module plus any `mod` blocks around it. */
+export function moduleOfDef(filePath, namespacePrefix, index) {
+    const fileModule = moduleOfFile(filePath, index);
+    if (fileModule === undefined)
+        return undefined;
+    if (namespacePrefix === undefined || namespacePrefix === '')
+        return fileModule;
+    return {
+        crateRoot: fileModule.crateRoot,
+        segments: [...fileModule.segments, ...namespacePrefix.split('.')],
+    };
+}
+/**
+ * Resolve a written path's leading segments to a module, from the calling
+ * module. Mirrors rustc's anchor handling:
+ *
+ *   crate::a::b   → the caller's OWN crate, segments ['a','b']
+ *   self::a       → callerModule ++ ['a']
+ *   super::a      → callerModule[:-1] ++ ['a']
+ *   a::b          → relative; the caller resolves this against the candidate
+ *                   channels (child module, `use` binding), so it is returned
+ *                   as-is for the caller to try in context.
+ *
+ * An anchored path always stays inside the caller's crate — `crate::` names the
+ * current crate, and `super::`/`self::` are relative to it — so the resolved
+ * module inherits `callerModule.crateRoot`.
+ *
+ * `super` chains (`super::super::x`) are consumed left to right. Returns
+ * `undefined` when the chain walks above the crate root — an invalid path that
+ * must not silently resolve to something else.
+ */
+export function resolveAnchoredModulePath(qualifier, callerModule) {
+    if (qualifier.length === 0)
+        return undefined;
+    const crateRoot = callerModule.crateRoot;
+    const head = qualifier[0];
+    if (head === 'crate' || head === '$crate') {
+        return { module: { crateRoot, segments: qualifier.slice(1) }, anchored: true };
+    }
+    if (head === 'self') {
+        return {
+            module: { crateRoot, segments: [...callerModule.segments, ...qualifier.slice(1)] },
+            anchored: true,
+        };
+    }
+    if (head === 'super') {
+        let i = 0;
+        const base = [...callerModule.segments];
+        while (i < qualifier.length && qualifier[i] === 'super') {
+            if (base.length === 0)
+                return undefined; // above the crate root
+            base.pop();
+            i++;
+        }
+        return { module: { crateRoot, segments: [...base, ...qualifier.slice(i)] }, anchored: true };
+    }
+    return { module: { crateRoot, segments: [...qualifier] }, anchored: false };
+}
+/**
+ * Identity comparison for two modules. The crate root participates: two modules
+ * with the same internal path in DIFFERENT crates are different modules, and
+ * conflating them is what let a workspace mis-bind or refuse (#2730 review H1).
+ */
+export function sameModule(a, b) {
+    return (a.crateRoot === b.crateRoot &&
+        a.segments.length === b.segments.length &&
+        a.segments.every((seg, i) => seg === b.segments[i]));
+}

package/dist/core/ingestion/languages/rust/qualified-call.d.ts

@@ -0,0 +1,41 @@
+/**
+ * Rust module-qualified call resolution (#2730) — path resolution over the
+ * module tree, the way rustc does it.
+ *
+ * `tools::dispatch(ctx, name)` is captured as a FREE call whose `name` is the
+ * tail identifier and whose written path rides along in `site.rawQualifiedName`
+ * (the same channel #1982 built for qualified inheritance bases). Without
+ * consulting that path, the shared scope-chain walk resolves the bare tail and
+ * binds it to whatever `dispatch` is lexically nearest — which, for the wrapper
+ * idiom `fn dispatch(..) { tools::dispatch(..) }`, is the wrapper itself. The
+ * real cross-module edge then does not exist and `impact` reports the callee as
+ * unreached.
+ *
+ * The fix follows rustc's actual rule rather than a filename heuristic:
+ *
+ *   1. A path's leading segments name MODULES, resolved in the type namespace.
+ *      A same-named `fn` lives in the value namespace and therefore can never
+ *      shadow them — which is exactly the shadowing this bug was about.
+ *   2. `crate::` / `self::` / `super::` are prefix transforms on the caller's
+ *      own module path, not reasons to give up.
+ *   3. The final segment is a MEMBER of the resolved module — looked up in that
+ *      module's binding table, so `pub use` re-exports resolve like any other
+ *      binding.
+ *
+ * Module identity comes from `module-path.ts`: file path below the crate root,
+ * plus any enclosing `mod` blocks (carried on `namespacePrefix`, stamped by the
+ * shared `tagNamespacePrefixes` pass now that `mod_item` emits a Namespace def).
+ *
+ * Refuses — returns `undefined`, leaving the shared chain untouched — whenever
+ * the path names no known module, the module has no such member, or two
+ * candidates tie. A wrong CALLS edge is worse than a missing one: it is what
+ * made this issue dangerous in the first place.
+ */
+import type { ParsedFile, ScopeId, SymbolDefinition } from '../../../../_shared/index.js';
+import type { ScopeResolutionIndexes } from '../../model/scope-resolution-indexes.js';
+import type { WorkspaceResolutionIndex } from '../../scope-resolution/workspace-index.js';
+export declare function resolveRustQualifiedFreeCall(site: {
+    readonly name: string;
+    readonly rawQualifiedName?: string;
+    readonly inScope: ScopeId;
+}, callerParsed: ParsedFile, scopes: ScopeResolutionIndexes, workspaceIndex: WorkspaceResolutionIndex, allFilePaths: ReadonlySet<string>): SymbolDefinition | undefined;