feat: SwiftPM package-graph support (Package.swift manifest resolution) for cross-package/cross-repo edges

[gsdali]

Summary

Cross-package/cross-repo linkage is manifest-driven (pass_pkgmap.c resolves bare specifiers via package.json, go.mod, Cargo.toml, …), but Package.swift (Swift Package Manager) is not a recognized manifest — so a SwiftPM ecosystem gets zero cross-package edges. Please add SwiftPM to the package-graph resolver.

This is the SwiftPM peer of the JS-workspace (#408), Cargo-crate (#56), and umbrella workspace (#271 / #398) work — not a duplicate; SwiftPM is simply absent.

Motivation

SwiftPM ecosystems are commonly many small packages: one core library + N consumers. The high-value query — "if I change Core.foo, which of the N consumers break?" — needs cross-package edges. Concrete real case: an ~17-package ecosystem (a binary-wrapper core + 13 consumers) where this is the daily question.

What's needed

1. Manifest resolution (the achievable, pattern-matching ask): parse Package.swift to map module/product names → packages:
   • dependencies: .package(url: "…/Foo.git", …) and .package(path: "../Foo")
   • target deps: .product(name: "Foo", package: "Foo") and target-name deps
   • then resolve Swift import Foo to the providing package → emit cross-package IMPORTS (and, where resolvable, USAGE/CALLS) edges. Mirrors the existing package.json/Cargo.toml path.
   • Caveat: Package.swift is executable Swift, not declarative — a lightweight pattern-extraction of the dependencies: / .product(...) literals (not full evaluation) covers the overwhelming majority.
2. Swift semantic tier (larger, noted as the precision dependency): Swift is currently tree-sitter-only ("Excellent" parse tier) with no Hybrid LSP, so cross-module CALLS resolve textually (ambiguous for common method names). Precise cross-package call graphs need a Swift semantic pass — cf. the LSP requests for Julia (Feature Request: Add Hybrid LSP support for Julia #535) / Perl (Add Perl LSP-tier semantic resolution (perl_lsp.c) #459) / Rust (Rust LSP #405). Manifest-level IMPORTS edges (item 1) are valuable even without this.

Observed (v0.8.1, macOS arm64)

Indexing a SwiftPM core + 2 consumers separately: per-repo graphs are excellent (core = 18.7k nodes / 70k edges / 7,776 funcs in 8 s; accurate CALLS/IMPORTS within a repo). But default indexing emits no CROSS_* edges between them, and index_repository mode=cross-repo-intelligence is HTTP/route-oriented (cf. #523) — there's no path that links a consumer's import Core / Core.foo() to the core package's definitions.

Acceptance

SwiftPM packages indexed under one store produce cross-package IMPORTS edges resolved through Package.swift (matching the package.json / Cargo.toml behavior). Precise cross-package CALLS tracked as a follow-up dependent on Swift semantic support.

[gsdali]

Happy to implement item 1 (SwiftPM Package.swift manifest resolution → cross-package IMPORTS edges) if you're open to it — it slots into the existing pass_pkgmap.c pattern with no new grammar (Swift tree-sitter is already vendored).

Proposed approach, mirroring the existing resolvers:

• add parse_package_swift(source, len, rel_path, …) — a hand-rolled extractor (in the spirit of parse_cargo_toml) pulling name:, products: [.library(name: "…")], and targets: [.target(name: "…")] string literals to map importable module names → the package/entry. Package.swift is executable Swift, so this is literal pattern-extraction (not full evaluation), which covers the overwhelming majority of real manifests.
• dispatch in cbm_pkgmap_try_parse (strcmp(basename, "Package.swift")) and add it to is_pkgmap_manifest_basename.
• this lets import Foo resolve to the providing SwiftPM target → cross-package IMPORTS edges, exactly like the package.json / Cargo.toml path.

Scope kept to ~item 1 only (well under the 500-line guideline); precise cross-package CALLS (item 2, a swift_lsp.c semantic tier) would be a separate follow-up. Would follow DCO sign-off, conventional commits, and clang-tidy/cppcheck/clang-format + ASan/UBSan tests.

Is this something you'd accept a PR for, and does the approach look right? Happy to adjust before coding.

[DeusData]

Hey, thx for the issue. Will check ASAP

[gsdali]

Now that this is in 0.9.2-rc — I'm still happy to open the PR for item 1 (the Package.swift manifest resolver → cross-package IMPORTS edges, scoped as above: a hand-rolled literal extractor in the pass_pkgmap.c pattern, no new grammar, well under the 500-line guideline). Want me to take it, or are you planning to? Just checking before I start so it matches your approach.

[DeusData]

Thanks for checking before starting. Please take item 1 as a focused 0.9.2-rc PR. Keep it to literal Package.swift manifest extraction and cross-package IMPORTS resolution, with RED fixtures for local path dependencies, remote package identities, products, targets, and target-name dependencies. Because Package.swift is executable Swift, dynamic or ambiguous expressions must fail closed rather than mint authoritative package edges.

Please do not include a Swift semantic tier, new grammar, dependency, configuration switch, or cross-package CALLS expansion in this PR. This is an invitation to submit the scoped change for review, not a merge commitment.