Feature request: Objective-C / Objective-C++ / Metal support

[FluxKo]

Feature request: Objective-C / Objective-C++ / Metal support

Currently .m, .mm, and .metal files are not in EXTENSION_MAP (src/extraction/grammars.ts), so they resolve to language: 'unknown' and are silently skipped during indexing — no error, no warning, they're just absent from the graph.

This matters for Apple-platform codebases (AVFoundation/VideoToolbox/Metal-heavy projects), where .m/.mm is often where the interesting call graph lives.

What I found while prototyping a fix locally

• tree-sitter-objc.wasm is already a transitive dependency — tree-sitter-wasms (a direct dependency of codegraph) ships it, but nothing wires it up. Adding objc: 'tree-sitter-objc.wasm' to WASM_GRAMMAR_FILES + .m → objc in EXTENSION_MAP is enough to load it.
• No field names for class/method identifiers in the objc grammar (class_interface/class_implementation/method_declaration/method_definition all carry the name as a positional, unlabeled identifier child), and @implementation methods nest two levels deep (class_implementation → implementation_definition → method_definition). The generic nameField-based extraction machinery can't drive this — it needs a visitNode-based extractor (same pattern as pascal.ts), building the full colon-separated selector (doA:andB:) from the identifier/method_parameter sequence.
• message_expression ([obj foo:1 bar:2]) needs custom handling too — it has no function field, so the generic extractCall falls back to node.namedChild(0) and picks up the receiver as the callee name. Has a method: field that repeats once per keyword segment.
• I built and tested a working extractor locally (~200 lines, modeled on c-cpp.ts/pascal.ts) against real .m fixtures (including #import <VideoToolbox/VideoToolbox.h> usage) — classes, selectors (unary/keyword/multi-keyword), and message-send call edges all extract correctly and resolve in the graph.
• .mm (Objective-C++): no grammar covers the actual mix. Empirically parsing representative .mm samples, tree-sitter-objc produces fewer ERROR nodes than tree-sitter-cpp — it's the better of two imperfect defaults, but embedded C++ class bodies inside .mm files still misparse. Worth flagging as a known limitation rather than pretending it's exact.
• .metal: no dedicated grammar exists (Metal Shading Language ≈ C++14 + attribute syntax). Mapping .metal → the existing cpp extractor works surprisingly well out of the box — functions and structs extract correctly; only the [[buffer(0)]]-style attribute annotations trip up the parser locally, without derailing the rest of the file.

Happy to share the local diff/extractor if useful as a starting point — not submitting as a PR since I only have the compiled dist/ output to work from locally, not your src/ layout/conventions.

[colbymchenry]

@FluxKo thank you for this detailed report. I'll get this in today. Thanks!

[colbymchenry]

Thanks for the unusually thorough report, @FluxKo — this is exactly the kind of write-up that's a joy to act on.

Good news on .m/.mm: that support already exists — it shipped in v0.9.5 (May 26) and has been extended several times since: full colon-separated selectors, [obj foo:1 bar:2] message-send call edges, chained [[X alloc] init] receiver resolution, content-sniffed Objective-C .h files, and .mm → the objc grammar for exactly the reason you found (fewer ERROR nodes than cpp, with embedded C++ bodies as the known limitation). Your local prototype independently landed on the same design we shipped, down to the visitNode-based extractor and the method: field handling on message_expression. Could you check codegraph --version? If it reports something older than 0.9.5 — or if you recently reinstalled and still see old behavior — run which codegraph too: an older install earlier on your PATH can shadow the new one.

.metal was a real gap, and you were right about the fix: as of #1151 it indexes via the C++ grammar — vertex/fragment/kernel functions, structs, type aliases, and call edges all land in the graph. One thing we found while validating your suggestion: the [[buffer(0)]]-style attributes weren't just parser noise — on struct fields they quietly produced false inheritance edges (struct → its own field's type), so we blank them before parsing (offset-preserving, .metal files only). Validated on llama.cpp's ggml-metal.metal (130 kernels, cross-function call edges resolve correctly) and SDL's shader file.

It'll be in the next release. Thanks again — reports with this level of ground truth make fixes fast.