fix(extract): attribute C/C++ CALLS edges to the enclosing function#463
Open
KerseyFabrications wants to merge 1 commit into
Open
fix(extract): attribute C/C++ CALLS edges to the enclosing function#463KerseyFabrications wants to merge 1 commit into
KerseyFabrications wants to merge 1 commit into
Conversation
A CALLS edge whose caller is a C/C++/CUDA/GLSL function was sourced to the file's Module node instead of the calling Function. "Find callers of X" returned a file path, outbound trace_path returned empty, and (:Function)-[:CALLS]->(:Function) queries missed for these languages. Root cause: the enclosing-function resolvers read only tree-sitter's `name` field, but a `function_definition` node has none — the name lives in the declarator chain (pointer/function/parenthesized/array declarators). So func_node_name() (internal/cbm/helpers.c) and resolve_func_name_node() (internal/cbm/extract_unified.c) returned NULL, the enclosing scope fell back to the module QN, and the edge was attributed to the Module node. This is the C counterpart to DeusData#220, which fixed the definition-naming path but not the enclosing-call path. Fix: descend the declarator chain to the innermost name node (mirroring resolve_c_declarator_name in extract_defs.c, including qualified and operator names) when a function_definition lacks a `name` field. Adds the regression test c_caller_attribution asserting a C call's enclosing_func_qn is the function, not the module. Fixes DeusData#438 Signed-off-by: Kris Kersey <kris@kerseyfabrications.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A CALLS edge whose caller is a C/C++/CUDA/GLSL function was sourced to the
file's Module node instead of the calling Function. "Find callers of X"
returned a file path, outbound trace_path returned empty, and
(:Function)-[:CALLS]->(:Function) queries missed for these languages.
Root cause: the enclosing-function resolvers read only tree-sitter's
namefield, but a
function_definitionnode has none — the name lives in thedeclarator chain (pointer/function/parenthesized/array declarators). So
func_node_name() (internal/cbm/helpers.c) and resolve_func_name_node()
(internal/cbm/extract_unified.c) returned NULL, the enclosing scope fell
back to the module QN, and the edge was attributed to the Module node. This
is the C counterpart to #220, which fixed the definition-naming path but not
the enclosing-call path.
Fix: descend the declarator chain to the innermost name node (mirroring
resolve_c_declarator_name in extract_defs.c, including qualified and operator
names) when a function_definition lacks a
namefield. Adds the regressiontest c_caller_attribution asserting a C call's enclosing_func_qn is the
function, not the module.
Fixes #438
Signed-off-by: Kris Kersey kris@kerseyfabrications.com