mirror of
https://github.com/colbymchenry/codegraph.git
synced 2026-09-19 07:34:57 +08:00
272d0e99a6
Indexing any C# project produced zero `references` edges: csharp | calls | 810 csharp | extends | 70 csharp | implements | 20 csharp | instantiates | 169 csharp | references | 0 <-- bug So `codegraph_callers SessionInfoDto` returned 0 hits even when the DTO was used as a parameter or return type across the codebase, and `codegraph_callees DataExporter` only saw `using` imports. Two root causes: 1. `csharp.ts` was missing `returnField`. The default `'return_type'` doesn't exist on C# method_declaration nodes — the field is `'type'`. Also `paramsField` was set to `'parameter_list'` (the node TYPE) instead of `'parameters'` (the field NAME on method_declaration), so parameter extraction silently no-op'd. 2. `extractTypeRefsFromSubtree` only emitted refs for `type_identifier` leaves. C# tree-sitter does not produce `type_identifier` — it uses `identifier`, `predefined_type`, `qualified_name`, `generic_name`, `array_type`, `nullable_type`, `tuple_type`, etc. Fix: - `csharp.ts`: set `paramsField:'parameters'` and `returnField:'type'`. - Route C# through a dedicated `extractCsharpTypeRefs` + recursive `walkCsharpTypePosition`. The walker descends ONLY into known type fields (parameter.type, method.type, property.type, variable_declaration.type, tuple_element.type), so parameter names like `request` in `Build(UserDto request)` are never mis-emitted as type refs. - Hook `extractField` and `extractProperty` to call `extractTypeAnnotations`. Previously neither emitted type references for any language; the C# branch in the new walker handles the `field_declaration → variable_declaration → type` nesting. Validation on dotnet/eShop (527 .cs files): references: 35 -> 925 (+26x) No regression in calls/imports/instantiates/extends/implements. Test covers method return type, parameter types, generic return (`Task<SessionInfoDto>`), property type, and field type all flowing to incoming `references` edges on the DTO/class — and confirms parameter names don't leak. Closes #381. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>