大规模原生代码 编程语言
Maguyva 的 C++ 支持：面向大型代码库的类与调用图
C++ 把真正的调用目标藏在命名空间、重载和虚派发背后。图谱帮助智能体把它找出来。
AST 和符号支持 AST 解析 符号提取 图谱关系
扩展名
.c, .c++, .cc, .cpp, 还有 6 个
打开指南
为什么 C 需要调用图，而不是 grep
C 没有用来组织代码的类或模块。结构存在于函数调用、头文件和结构体之中，同一个名字还可能出现在注释、宏和字符串字面量里。导出宏和注解宏会包裹声明，这会让只能解析纯 C 的工具出错。对智能体来说，稳妥的第一步就是调用图。
Maguyva 会构建这张图，让智能体在提出修改之前，就能看清一个函数会调用到什么、又被什么调用。
Maguyva 在 C 中提取什么
Maguyva 覆盖 .c 和 .h。函数定义会被提取为符号，结构体和联合体可以在结构搜索中作为类型定义选取。#include 指令会成为导入关系。
导出和可见性宏（如 FOO_API、DLLEXPORT 或 LIBEXPORT 这类模式）以及线程安全注解宏（如 GUARDED_BY 和 REQUIRES）会在解析前被屏蔽，因此被它们包裹的声明仍然能作为声明解析。类函数宏的宏体会被解析；类对象宏的宏体则不会。
图谱记录调用、头文件包含、复合字面量实例化、类型引用、读写以及控制流。约 124 个标准 C 库调用（printf、malloc、free、memcpy、strlen 等）会从关系中过滤掉，让项目代码更加突出。
智能体提示词示例
- “谁调用了
uart_write，无论是直接调用还是经由其他函数？”（dependency_search的 incoming 方向） - “哪些文件包含了
config.h，它们使用了其中哪些结构体？”（先用dependency_search，再用find_symbol） - “解释一个数据包如何从接收中断流转到协议解析器。”（
get_task_context）
已知限制
- C 没有类，也没有异常，因此继承、接口实现、重写、抛出和捕获关系被标记为不适用。
.h同时出现在 C、C++ 和 Objective-C 的扩展名列表中，因此混合语言的头文件由这些配置共享。- 对已过滤标准库函数的调用不是图谱的边。需要找出每一个
malloc或memcpy时，请使用text_pattern_search。
后续步骤
最适合场景
- > 固件、嵌入式和操作系统团队，对共享函数的一个小改动就可能波及硬件路径。
- > 长期维护的 C 库，带有公共头文件、导出宏和大量内部翻译单元。
- > 智能体辅助的评审，核心问题是“谁在调用它，经由哪些头文件？”
智能体工作流
- > 在修改函数签名或错误处理之前，找出它的所有调用方。
- > 梳理哪些文件包含了某个头文件，以及它们使用了哪些结构体。
- > 从中断处理程序或入口点出发，追踪一个请求所到达的函数。
引擎细节
- > C 支持覆盖 `.c` 和 `.h`。函数定义是符号，结构体和联合体是类型定义，`#include` 会成为导入关系。
- > 导出、可见性和线程安全注解宏会在解析前被屏蔽，因此被包裹的声明仍能解析。类函数宏的宏体会被解析；类对象宏的则不会。
- > 约 124 个标准库调用（如 `printf`、`malloc` 和 `memcpy`）会被过滤掉。继承、重写和异常关系被标记为不适用。
常用 MCP 入口工具
- find_symbol
需要定义和所有引用时，用函数名或结构体名来查找。
- dependency_search
在修改共享函数的签名或错误处理之前，使用 incoming 遍历。
- get_task_context
适用于“解释一个数据包如何从接收中断流转到协议解析器”这类提示词。