graphify version: 0.9.10 (pip package graphifyy)
Language: C#
Corpus: ~6,300 C# files, AST-only extraction via graphify update <path> (no LLM/semantic backend configured)
Bug
A method call chained directly onto a new X(...) object-creation expression (no intermediate variable) is not captured at all — neither as a calls edge to the invoked method, nor as a references/instantiation edge to the constructed type.
Repro
Source (ToolProductSvc.cs):
public ConnectableItemsGroupInformation GetMachineConnectableItemsInformationExt(
GetConnectableItemsContext getConnectableItemsContext)
{
return new StatefulFiltersMerger(getConnectableItemsContext.QueryContextFields)
.GetConnectableItemsInformation(getConnectableItemsContext, true);
}
Expected: a calls edge from GetMachineConnectableItemsInformationExt to StatefulFiltersMerger.GetConnectableItemsInformation, and/or a reference edge to the StatefulFiltersMerger class.
Actual: the caller's node has zero calls edges. Its only outgoing edges are two references edges — to ConnectableItemsGroupInformation (return type) and GetConnectableItemsContext (parameter type). Nothing points at StatefulFiltersMerger or .GetConnectableItemsInformation(), even though both of those nodes exist correctly elsewhere in the same graph.
Verified via direct inspection of the output graph.json:
- Caller node id:
webservices_toolproductsvc_machiningcloud_server_webservices_toolproductsvc_getmachineconnectableitemsinformationext — outgoing edges: 2 references, 0 calls.
StatefulFiltersMerger class node exists correctly at Source/Server/Logic/ToolProduct/Filters/StatefulFiltersMerger.cs:L55.
.GetConnectableItemsInformation() method node exists correctly at Source/Server/Logic/ToolProduct/Filters/StatefulFiltersMerger.cs:L126.
- No edge of any relation connects the caller to either of those two nodes, in either direction.
Suspected cause
The call-graph pass likely only attributes a calls edge when the receiver of a method call is a resolvable named symbol (local variable, field, parameter). A call fluently chained directly onto a new X(...) expression — i.e. new X(...).Method() with no assignment — appears to fall outside what the extractor's call-detection matches, and the constructor invocation itself isn't recorded as a reference either.
This is likely systematic rather than a one-off: any fluent/chained call directly off a constructor invocation anywhere in a C# corpus would silently disappear from the graph rather than erroring or warning, which could meaningfully understate a class's real dependencies/call graph.
Environment
- graphify 0.9.10 (
graphifyy on PyPI)
- OS: Windows 11
- Extraction:
graphify update <path> (AST-only, C# tree-sitter grammar)
graphify version: 0.9.10 (pip package
graphifyy)Language: C#
Corpus: ~6,300 C# files, AST-only extraction via
graphify update <path>(no LLM/semantic backend configured)Bug
A method call chained directly onto a
new X(...)object-creation expression (no intermediate variable) is not captured at all — neither as acallsedge to the invoked method, nor as areferences/instantiation edge to the constructed type.Repro
Source (
ToolProductSvc.cs):Expected: a
callsedge fromGetMachineConnectableItemsInformationExttoStatefulFiltersMerger.GetConnectableItemsInformation, and/or a reference edge to theStatefulFiltersMergerclass.Actual: the caller's node has zero
callsedges. Its only outgoing edges are tworeferencesedges — toConnectableItemsGroupInformation(return type) andGetConnectableItemsContext(parameter type). Nothing points atStatefulFiltersMergeror.GetConnectableItemsInformation(), even though both of those nodes exist correctly elsewhere in the same graph.Verified via direct inspection of the output
graph.json:webservices_toolproductsvc_machiningcloud_server_webservices_toolproductsvc_getmachineconnectableitemsinformationext— outgoing edges: 2references, 0calls.StatefulFiltersMergerclass node exists correctly atSource/Server/Logic/ToolProduct/Filters/StatefulFiltersMerger.cs:L55..GetConnectableItemsInformation()method node exists correctly atSource/Server/Logic/ToolProduct/Filters/StatefulFiltersMerger.cs:L126.Suspected cause
The call-graph pass likely only attributes a
callsedge when the receiver of a method call is a resolvable named symbol (local variable, field, parameter). A call fluently chained directly onto anew X(...)expression — i.e.new X(...).Method()with no assignment — appears to fall outside what the extractor's call-detection matches, and the constructor invocation itself isn't recorded as a reference either.This is likely systematic rather than a one-off: any fluent/chained call directly off a constructor invocation anywhere in a C# corpus would silently disappear from the graph rather than erroring or warning, which could meaningfully understate a class's real dependencies/call graph.
Environment
graphifyyon PyPI)graphify update <path>(AST-only, C# tree-sitter grammar)