3 Commits

Include renames

Author	SHA1	Message	Date
Colby MchenryandClaude Opus 5.5	65d734236e	fix(rust): a private item, or one another crate holds, no longer takes a name a file imports (#2692) ... A Rust type alias declared without pub recorded no visibility in either engine, so name matching took dioxus's private type Result in src/build/patch.rs for the Result<...> a file means through use crate::Result. Type aliases now record it, as functions and structs already do, and a private module item is out of scope outside its own module ahead of the ranking. The pipeline's veto already rejected such a pick after the ranking, which left the reference unresolved: that is what kept tokio's timeout(...), split(...) and sleep(...) calls from linking, since a private namesake outranked the function they import. With the private items gone, a runner-up from an unrelated crate could win instead: tokio's tests' spawn(...) calls, under use tokio_test::task::spawn, went to the examples crate's pub fn spawn. So a name a use binds is now an item of the crate its path starts from, or of a project crate that one's [dependencies] name, in turn, which a facade's re-exports need: clap::Command is clap_builder's. crate::, self:: and super:: start from the file's own crate; a named root counts when the file's own manifest lists it. Dependencies are found by path (their own, or the workspace's for workspace = true), so renamed keys and crates outside the members land, and dotted keys such as helper.workspace = true are read. Dev and build dependencies are not re-exported, so they don't count: tokio's own use crate::spawn, whose spawn sits in a macro the index doesn't see, stays unresolved instead of going to tokio-test's. A file in no crate the manifests name, or a path from anything else, is matched as before. reference-target-kind's sibling-crate fixture re-exported pupil_core without depending on it, which Cargo rejects; it now declares it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-20 00:44:52 +00:00
Colby MchenryandClaude Opus 5.5	49607201d6	fix(resolution): bind implements to the interface of a value+interface pair (#2055) ... The inheritance target-kind gate (#1796) rejected any extends/implements resolution whose target cannot be a supertype. VS Code declares every service twice under one name, `export const IFoo = createDecorator<IFoo>(…)` beside `export interface IFoo`, and the import resolver takes the first export of that name, which is the value. The gate then dropped the edge instead of taking the interface the same file declares. Found by the pre-release v1.6.0 vs main comparison: 864 `implements` edges lost on vscode (AccessibilityService -> IAccessibilityService and ~860 like it), plus the ~5.8k interface-dispatch call edges synthesized from them. The gate now moves a TypeScript constant/variable target to the one same-named supertype in its file; with no such sibling it still drops the edge. vscode: implements 4,139 -> 5,003 (v1.6.0: 5,436, 254 of them on non-type targets; now 0), node count unchanged. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 19:55:29 +00:00
3 people	374b3b4209	fix(resolution): constrain inheritance/import reference target kinds (#1536, #1537) (#1796) ... * fix(resolution): gate extends/implements to real supertypes An inheritance reference bound to whatever local symbol shared its name. The name-matcher scores node kind as a bonus, never a filter, and awards no bonus at all for inheritance refs, so `use std::error::Error;` + `impl Error for MapperError {}` resolved to the local `MapperError::Error` VARIANT — an implementation relationship absent from the source. Two changes, both needed. Filtering by kind alone was measured and it only RELOCATES the false edge: with enum members excluded, the same 7 refs moved onto an unrelated local `type Error` alias, which is a legal supertype kind and therefore harder for a consumer to reject. 1. Eligibility before ranking. `matchByExactName` restricts its candidate pool to kinds that can BE a supertype, so a legitimate trait outranks a same-named variant instead of merely losing its edge. `resolveOne` is wrapped by a gate that applies the same set to every other strategy at one seam — filtering inside the name-matcher would have missed the framework, import, chain and CFML paths. 2. Locality. A name imported from outside the repository has no in-repo referent at all, so no candidate is correct. Only oracles that cannot be wrong are consulted: Rust `use` paths rooted at a stdlib crate, and `isExternalImport` for ES modules. Generalizing the Rust side to "the module path doesn't resolve to a file" was tried and reverted — a crate re-exporting a sibling's modules (`pub use pupil_core::ports;`) has no directory to walk, and that version deleted 13 real trait implementations. Measured on a Rust/Tauri project (2,682 nodes): the 11 false inheritance edges are gone, all 59 real trait relationships are preserved, and node count is unchanged. On this repository as a control, the only edge removed is a class recorded as extending a function. Synthesized-edge counts are identical in both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(resolution): an import never resolves to a member of a type `import * as path from 'node:path'` is unresolvable — the module is external — so the name-matcher fell back to finding any node called `path`, and a common word like path/url/join/get matches a class property or interface method somewhere in almost any repo. Nothing in any supported language lets an import bind to a member that only exists inside a type; you import the type. Same shape as the inheritance gate that precedes it: eligibility applied to the candidate pool before ranking, plus the resolveOne gate as the backstop for every other strategy. On this repository as a control: 19 imports pointing at methods and 4 at properties are gone (all of them coincidences — `Walker::join`, `Telemetry::events`), 3 refs now find the module constant they actually name, node count unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(resolution): classify SFC script imports as ES module specifiers `isExternalImport` had a TS/JS branch listing typescript/tsx/javascript/jsx/ arkts, so for Svelte, Vue and Astro it fell through every branch and returned false — "not external" — for `import { Foo } from 'some-npm-pkg'`. An SFC imports inside its `<script>` block (Astro: the `---` frontmatter) with ordinary ES module syntax; `extractImportMappings` already routes all three through the same `extractJSImports`. So the classifier disagreed with the extractor about what those imports are. Effect on the preceding commit: its locality check asks `isExternalImport`, so it silently did nothing for SFCs. A class in a `.svelte`/`.vue`/`.astro` file implementing a type imported from an npm package still bound to whatever local class shared that name — verified against this branch before the fix, all three languages. The language set is now one constant used by both the classifier and the locality check, so they cannot drift apart again. Relative and aliased specifiers are unaffected: the branch returns "not external" for `./…`, workspace members, tsconfig alias prefixes, `@/`, `~/` and `src/` exactly as it does for `.ts`. No edge changes on this repository as a control. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: ctype_lab <cksgud1226@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>	2026-09-08 15:49:10 -05:00