PR #486 - bompus/codegraph

Brings upstream/main from 041db101 to c19f0284 into fork/consolidated: four upstream fixes (#2528 to #2531). Merge commit, not squash, so upstream's history stays a parent.

What came in, and where it lives in the fork

Upstream	Change	In the fork
#2528	An import in a Vue, Svelte or Astro component, and an import of a scoped package that a `tsconfig` path or workspace package maps to a file, link the module file; sync retries failed imports by the specifier that now resolves	Resolver side was already native (`is_js_path_import_ref` covers `svelte`/`vue`/`astro` and scoped paths). Ported the sync half into `src/codegraph.ts` (upstream put it in `src/index.ts`, which the fork split) and the new `QueryBuilder` lookups
#2529	Sync moves an import to an added file that outranks the one it found (`./button`: `button.vue` then `button.ts`)	`src/resolution/module-importers.ts` and `src/codegraph.ts`, with `ReferenceResolver.resolveModuleFile`
#2530	A smart pointer's held class that lacks a method gets no edge only when its bases are all known	One condition in `codegraph-kernel/src/resolve/cpp_receivers.rs`: the bases-known check now applies to held types too
#2531	A declaration inside a string literal is not a receiver's declaration	Nothing to port: the fork's AST-first receiver lookup already passes upstream's new tests on `ba4f7e38` (run on the base build). The TS files `name-matcher.ts` and `cpp-raw-strings.ts` stay deleted

Deliberate differences from upstream

__tests__/cpp-smart-pointer-receiver.test.ts: for a held class with an unlinked base, upstream's test expects the call to fall back to a guess by method name. The fork's fallback guesses no method for a receiver whose class it knows, so the call stays unresolved, as the fork's existing test for a reference expects in cpp-declared-type-receiver.test.ts. The new test expects [] and says why. The #2530 change therefore does not change this fixture's result on the fork; it keeps the held and non-held paths on one rule.
CHANGELOG.md: the fork's [Unreleased] already lists upstream's earlier entries in a different order, so a plain merge duplicated 39 of them. Kept the fork's file and applied upstream's changes by hand: two new import entries and the reworded smart-pointer entry, which now says an unlinked base leaves the call unlinked. Upstream's string-literal entry is left out because the fork already satisfied it.

Checks

Full local suite on 048a2418: 700 files, 8926 passed, 39 skipped, 0 failed (vitest run, kernel and viewer rebuilt first; clippy -D warnings clean).
The four new or changed upstream test files pass on the fork: sfc-alias-module-imports, sync-module-importers (12), cpp-string-literal-declarations (3), cpp-smart-pointer-receiver (9).
README rows checked: the merge point in the "About this fork" paragraph (041db101 to c19f0284). No benchmark row or count moves: nothing here touches indexing speed or memory, and no kernel golden dump changed.

Summary by cubic

Brings upstream main through c19f0284 into fork/consolidated: four fixes (#2528–#2531), merged with a merge commit so upstream history stays a parent. The fork's full suite passes and all four changed upstream tests pass on it.

#2528 — imports in Vue, Svelte or Astro components, and of a scoped package a tsconfig path maps to a file, now link the module file; sync retries such failed imports by specifier. The resolver side was already native; the sync half was ported.
#2529 — sync moves an extensionless import to an added file that outranks the one it found (./button finds button.ts over button.vue).
#2530 — a smart pointer's held class that lacks a method gets no edge only when all its bases are known.
#2531 — a declaration inside a string literal is no longer taken for a receiver's declaration; nothing to port, the fork's receiver lookup already passes.

Deliberate differences from upstream

CHANGELOG.md: a plain merge duplicated 39 [Unreleased] entries, so the fork kept its own file and applied upstream's changes by hand — the string-literal entry was dropped because the fork already satisfies #2531, and the held-class entry states the call now stays unlinked.
cpp-smart-pointer-receiver.test.ts: where upstream's test expects a fallback guess by method name, the fork's fallback guesses no method for a receiver whose class it knows, so the new test expects [] and explains why.

Summary by CodeRabbit

Bug Fixes
- C++ calls through smart pointers and optionals remain unresolved when the held type’s method or inheritance cannot be determined, avoiding incorrect method matches.
- Vue, Svelte, and Astro component imports are linked to their imported files, including imports through configured aliases.
- When a newly added file takes precedence for an extensionless import, the importer is updated to reference it.
- C++ declarations inside string and character literals do not interfere with receiver detection or method-call resolution.