[codex] add go support

[CaliLuke]

Summary

Adds Go language support to llmcc using tree-sitter-go and the existing language-crate architecture.

The new llmcc-go crate covers parsing, token generation, symbol collection, binding, and basic type inference for package/file hierarchy, named types, structs, interfaces, fields, parameters, functions, methods, locals, return types, and straightforward call/type relationships.

Details

• Adds a Go language crate wired into the workspace.
• Enables --lang go / --lang golang in the CLI.
• Exposes Go through the Python bindings.
• Adds Go support to the corpus runner and benchmark file/LoC helpers.
• Updates README language status.
• Adds a Go corpus fixture for named types, parameters, returns, and architecture graph edges.
• Uses Go package-directory scopes for binding so common names in different packages do not collide globally.
• Keeps Go methods out of the package-level unqualified namespace so repeated method names such as Close do not pollute package lookup.

Validation

• cargo fmt --all --check
• cargo check --workspace
• cargo run -q -p llmcc-test -- run tests/go/render/01_named_types_and_functions.llmcc
• Real-code smoke test on /Users/luca/code/autok/autok-server with 7,538 Go files:
  • cargo run -q -p llmcc -- -d /Users/luca/code/autok/autok-server --lang go --graph --depth 3 --pagerank-top-k 200 -o <tmp.dot>
  • completed successfully
  • resolver ambiguity warnings: 0

[allenanswerzq]

Hi, @CaliLuke thanks you so much for the interests for this idea/project, kind already losing passion for it myself. I know this is a hard problem, so far still not good solution for it.

On the PR side, because this is a very very early project, I am very flexiable to check stuff in (human or ai code all welcome), will take a brief review, and get it checked in so you can do more experiments with it.

huge thanks.

[CaliLuke]

sure no problem, I wanted to experiment with the same concept and didn't want to rewrite the whole thing by hand so I added go support to your project instead. I think the tree built by the tool is a bit verbose and probably not hyper helpful but it helped the agent catch a few things that were genuinely in the wrong place after a refactor so it's the kind of tool that might end up in my personal harness as pre-commit or pre-push kind of check.

[allenanswerzq]

"I think the tree built by the tool is a bit verbose", yes, thats great call, the reason its verbose, is becuase right now the tree is for people/human to render and see, not best fit the agents, should improve on that.