Clang libTooling中runToolOnCode是轻量级AST调试方式，但需显式传入编译参数如"-std=c++17"，仅支持单TU且不启用C++新特性；正确获取ASTContext需调用getASTContext()，节点指针随ASTContext析构而悬空。
Clang 的 libTooling 是目前 C++ 源码解析为 AST 最可靠、最贴近编译器语义的方案，但直接上手容易卡在环境配置、AST 遍历逻辑和编译参数传递这三关。
如何用 clang::tooling::runToolOnCode 快速验证单个函数的 AST 结构
这是最轻量的入门方式，适合调试 AST 节点类型和字段，无需构建完整工具链。它绕过文件系统和编译数据库，直接对内存中字符串做解析，但只支持单一翻译单元且默认不启用 C++11+ 特性。
- 必须显式传入编译参数，比如
{"-std=c++17", "-I/usr/include/c++/11"}，否则auto、std::vector等会解析失败 -
runToolOnCode返回的是std::unique_ptr<:astunit></:astunit>，其getASTContext()才能拿到ASTContext，进而调用getTranslationUnitDecl() - 常见错误：
clang::ast_type_traits::DynTypedNode::get报 nullptr —— 实际是节点未被正确遍历，不是 API 问题，而是TraverseDecl或Visit*Expr没被触发
#include "clang/AST/AST.h"
#include "clang/Tooling/Tooling.h"
#include "clang/Tooling/ASTToolingExample.h"
struct SimpleASTVisitor : public clang::RecursiveASTVisitor<SimpleASTVisitor> {
bool VisitFunctionDecl(clang::FunctionDecl *D) {
llvm::errs() << "Found function: " << D->getNameAsString() << "\n";
return true;
}
};
int main() {
auto AST = clang::tooling::buildASTFromCodeWithArgs(
"void foo() { int x = 42; }",
{"-std=c++17"});
SimpleASTVisitor Visitor;
Visitor.TraverseAST(AST->getASTContext());
}
为什么 clang::RecursiveASTVisitor 的 Visit*Decl 不触发
根本原因在于 Clang 的 AST 构建分两阶段：词法/语法解析（Sema）和语义分析（Sema），而 RecursiveASTVisitor 只遍历已完成语义分析的 Decl —— 如果代码有语法错误、缺失头文件或模板未实例化，对应 Decl 就不会进入 AST。
- 检查
D->isThisDeclarationADefinition()和D->hasBody()，很多FunctionDecl是声明而非定义，VisitFunctionDecl仍会调用，但getBody()返回空指针 - 模板类成员函数需显式实例化才能出现在 AST 中；否则只看到
FunctionTemplateDecl，看不到具体CXXMethodDecl - 使用
clang::ast_matchers替代手写 Visitor 更鲁棒，例如functionDecl(hasBody(stmt()))能精准过滤出带实现的函数
如何让 libTooling 正确加载项目头文件和宏定义
靠 runToolOnCode 无法模拟真实构建环境，必须用 clang::tooling::ClangTool + CompilationDatabase，否则 #include "xxx.h" 全部报错，__GNUC__ 等宏也不生效。
立即学习“C++免费学习笔记（深入）”；
- 生成
compile_commands.json最简单方式：CMake 加-DCMAKE_EXPORT_COMPILE_COMMANDS=ON，不要手动拼接 JSON - 路径必须是绝对路径，
clang::tooling::JSONCompilationDatabase::loadFromFile()对相对路径静默失败 - 若项目用 Ninja 或 Bazel，可用
intercept-build（scan-build 工具）捕获编译命令，再转成 JSON - ClangTool 构造时传入
new clang::tooling::FixedCompilationDatabase(".", json_path)，第二个参数不能是空字符串
AST 节点生命周期与内存管理的关键陷阱
clang::ASTContext 拥有所有 AST 节点的内存，一旦它析构（比如 ASTUnit 被释放），所有指向 Decl*、Stmt* 的裸指针立刻悬空 —— 这是 Segmentation Fault 最隐蔽的来源。
- 不要把
FunctionDecl*存进全局容器或跨函数返回；如需持久化，应拷贝关键字段（如名字、行号、参数类型名） -
clang::SourceManager和clang::LangOptions必须和ASTContext同生命周期，否则D->getLocation().print(...)可能崩溃 - 调试时用
clang::ast_dump()输出到字符串再打印，比直接llvm::errs()安全，它内部做了节点有效性检查
真正难的从来不是写出第一个 AST 遍历器，而是让工具在包含模板特化、模块接口单元（C++20 Modules）、预编译头（PCH）的大型项目里稳定跑完 —— 这些场景下，编译参数、AST 上下文隔离、跨 TU 符号解析才是核心门槛。
