Go backend

[lamwassi]

Feature request: Go static-analysis backend for CLDK (codeanalyzer-go / cango)

Is your feature request related to a problem? Please describe.

CodeLLM-DevKit (CLDK) provides LLM tooling with a uniform, language-agnostic view
of a codebase — its symbol table and call graph — via a per-language analyzer
backend that emits a canonical analysis.json. Backends already exist for
Java,
Python, and
TypeScript, but
there is no Go backend. As a result, the CLDK Python SDK cannot analyze Go
projects — CLDK(language="go").analysis(...) has nothing to call — so any
LLM-assisted workflow that relies on structured code facts (symbol lookup,
call-graph reachability, cross-package navigation) is unavailable for the entire
Go ecosystem.

Describe the solution you'd like

A self-contained Go static-analysis backend, distributed as a single static
binary (cango, aliased codeanalyzer-go), that emits the canonical CLDK
analysis.json and is spine-compatible with the Java/Python/TypeScript
analyzers so the Python SDK can load it directly.

Concretely, the backend should:

• Emit a symbol table — packages, structs, interfaces, fields, methods,
  package-level functions, imports, struct tags, and Go 1.18+ generics, each
  with precise source spans. Keyed by file path relative to the project root.
• Emit a resolver-based call graph — for each call site, resolve the callee
  to its full import-path signature via go/types, emitting project-internal
  edges (identity-only: source/target are signature strings present in the
  symbol table).
• Support analysis levels — Level 1 (symbol table only, default) and
  Level 2 (Level 1 + resolver call graph), with a stubbed CodeQL enrichment
  seam matching the Python/Java analyzers.
• Be built on golang.org/x/tools/go/packages — a single API giving both
  AST and full type resolution, handling Go modules natively.
• Ship self-contained — go build with CGO_ENABLED=0, no runtime
  dependencies for SDK users; distributed via shell installer, Homebrew, and a
  PyPI wheel (pip install codeanalyzer-go) that the SDK uses to locate the
  backend through codeanalyzer_go.bin_path().
• Expose a familiar CLI — cango -i /path/to/project -a {1,2}, with output
  to stdout or a directory, incremental (target-files) mode, caching, and an
  --eager clean-rebuild flag.

Success criterion: CLDK(language="go").analysis(project_path=...) returns a
populated symbol table and call graph for a real Go module.

Describe alternatives you've considered

• Reuse an existing analyzer's frontend and shell out to a Go tool — rejected
  because none of the existing backends parse Go, and the SDK contract is one
  binary per language emitting the canonical schema.
• Build only the AST/symbol table with go/ast (no type resolution) —
  insufficient: without go/types the call graph can't resolve callees to
  import-path signatures, so cross-package reachability (the main SDK use case)
  would be missing. go/packages is needed for module-aware type resolution.
• Use CodeQL as the primary call-graph engine — heavier to install and run,
  and inconsistent with the "rapid Level 1" default of the sibling analyzers;
  better kept as an optional Level-2 enrichment path (stubbed for now).
• Distribute as a Go-source dependency requiring a Go toolchain — rejected
  so SDK users need nothing installed; a prebuilt static binary bundled in the
  PyPI wheel keeps the zero-dependency install story.

Additional context

This backend is the Go sibling in the CLDK analyzer family, mirroring the
Java,
Python, and
TypeScript
analyzers, and consumed by the Python SDK.
The canonical output root is GoApplication (symbol_table, call_graph,
entrypoints), using JSON keys classes (for types) and module_name (for the
Go package name) to stay spine-compatible with the Java/Python schemas.