Skip to content

Unify call edge representation across language backends #204

Description

@tanbing117

##Background

FM-Agent currently supports multiple language backends (codegraph, regex-based extractors, and other language handlers). However, the call edge representation returned by these backends is inconsistent.

The current interface mainly uses:

{
caller_fqn: {
callee_fqn,
...
}
}

This representation is sufficient for top-down layer generation, but it loses important edge metadata and makes it difficult for future analyses (e.g., security plugins) to consume call graph information consistently.

##Problem

The current call edge interface has several limitations:

  1. Edge metadata is lost

Different backends may distinguish different edge types, such as:

normal function calls
constructor calls

However, the current FQN-set representation merges them into the same relation:

caller -> {callee1, callee2}

The edge type information cannot be preserved.

  1. Call-site information is unavailable

The current representation only stores:

caller function -> callee function

It does not preserve where the call happens.

This prevents downstream analyses from reliably associating source-level information with a specific call site.

For example:

check(password)
check(token)

Both become:

foo -> check

and the two call sites cannot be distinguished.

  1. Backend formats are inconsistent

Different language handlers currently return different formats:

dictionary-based edges:
{
caller: {callee}
}
list-based edge objects:
[
{
"caller": "...",
"callee": "..."
}
]
custom edge objects

Every consumer must understand each backend's format separately.

This makes extending the call graph interface difficult.

##Proposal

Introduce a normalized call edge representation inside the language registry layer.

All language backends should be converted into:

[
{
"caller": FunctionId,
"callee": FunctionId,
"kind": "call" | "constructor",
"language": str,
"span": {
"file": str,
"start_line": int,
"start_column": int,
}
}
]

The normalization layer should:

accept existing backend formats
validate required fields
normalize optional metadata
deduplicate edges at call-site granularity
preserve backend-specific information when available翻译

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions