1. 写在前面

在上篇博客中已经介绍了LLVM下载流程和LLVM的编译流程，也对编译完成的LLVM工程进行了 Clang和clangTooling的编译。


iOS底层探索之LLVM(二)——自定义Clang插件(上)

iOS底层探索之LLVM(一)——LLVM初体验

本篇博客将手把手教大家，进行代码编写，自定义一个 Clang插件，最终实现的功能是对不正确使用属性修饰会进行报错，并提示正确的用词，实现效果如下。

2. 前期准备

2.1 新建插件

在/llvm/tools/clang/tools目录下新建插件JPPlugins(这个是你自己建的，名字随便都可以，你自己知道就可以)

2.2 修改CMakeLists.txt

修改/llvm/tools/clang/tools目录下的文件CMakeLists.txt，新增加一句add_clang_subdirectory(JPPlugins)

  • 在JPPlugins目录下新建一个名为JPPlugins.cpp的文件和CMakeLists.txt的文件， 在CMakeLists.txt中写上如下代码

add_llvm_library( JPPlugins MODULE BUILDTREE_ONLY
JPPlugins.cpp
)

2.3 编译插件

  • 接下来再次使用cmake命令重新生成一下xcode项目，还是在llvm_build目录中 使用cmake -G Xcode ../llvm命令。
  • 最后可以在LLVM的Xcode项目中可以看到 Loadable modules 目录下有自己的Plugin目录了，我兴致勃勃的打开工程一看。。。。。

什么？居然失败了，什么都没有啊！这是在和我开玩笑吗？我仔细一看，是否是 JPPlugins.cpp文件和JPPlugins插件同名导致失败的呢？我于是改了下 cpp的名称，同时把插件名的s去掉了，还真就成功了！这就让我百思不得解了，就很奇怪！

  • 我这倔脾气，我就不信这个邪了，我又改回原来最初的名称， JPPlugins.cpp文件和JPPlugins插件依然是同名，我又编译了一次，发现还是失败了。
  • 我又改成 JP.cpp文件和插件名为JPPlugins，这回不一样了，该成功了吧！结果还是失败了。
  • 我又进行了第三次尝试， JPPlugin.cpp文件和插件名为JPPlugin，这回我把s去掉了，就是这么奇怪，这回成功了。


我也不去下什么结论， 反正同名的是可以编译成功的，具体是不是有s的后缀导致的，我也不知道，反正我这两次的成功是和这个有关，时间比较多的老铁可以去验证一下，这里就不再折腾去验证了。

那么我们现在就可以去 cpp里面编写Clang插件的代码了。

3. 编写插件代码

废话不多写，直接上代码，步骤就不一一列出来了，都写在代码里面了。


#include <iostream>
#include "clang/AST/AST.h"
#include "clang/AST/DeclObjC.h"
#include "clang/AST/ASTConsumer.h"
#include "clang/ASTMatchers/ASTMatchers.h"
#include "clang/Frontend/CompilerInstance.h"
#include "clang/ASTMatchers/ASTMatchFinder.h"
#include "clang/Frontend/FrontendPluginRegistry.h"// 声明使用命名空间
using namespace clang;
using namespace std;
using namespace llvm;
using namespace clang::ast_matchers;// 插件命名空间
namespace JPPlugin {// 第三步：扫描完毕回调// 4、自定义回调类，继承自MatchCallbackclass JPMatchCallback : public MatchFinder::MatchCallback {private:// CI传递路径：JPASTAction类中的CreateASTConsumer方法参数 -> JPASTConsumer的构造函数 -> JPMatchCallback的私有属性，通过构造函数从JPASTConsumer构造函数中获取CompilerInstance &CI;// 判断是否是自己的文件bool isUserSourceCode(const string fileName) {// 文件名不为空if (fileName.empty()) return false;// 非Xcode中的代码都认为是用户的if (0 == fileName.find("/Applications/Xcode.app/")) return false;return true;}// 判断是否应该用copy修饰bool isShouldUseCopy(const string typeStr) {// 判断类型是否是 NSString / NSArray / NSDictionaryif (typeStr.find("NSString") != string::npos ||typeStr.find("NSArray") != string::npos ||typeStr.find("NSDictionary") != string::npos) {return true;}return false;}public:// 构造方法JPMatchCallback(CompilerInstance &CI):CI(CI) {}// 重载run方法void run(const MatchFinder::MatchResult &Result) {// 通过Result获取节点对象，根据节点id("objcPropertyDecl")获取(此id需要与JPASTConsumer构造方法中bind的id一致)const ObjCPropertyDecl *propertyDecl = Result.Nodes.getNodeAs<ObjCPropertyDecl>("objcPropertyDecl");// 获取文件名称（包含路径）string fileName = CI.getSourceManager().getFilename(propertyDecl->getSourceRange().getBegin()).str();// 如果节点有值 && 是用户文件if (propertyDecl && isUserSourceCode(fileName)) {// 获取节点的类型，并转成字符串string typeStr = propertyDecl->getType().getAsString();// 节点的描述信息ObjCPropertyAttribute::Kind attrKind = propertyDecl->getPropertyAttributes();// 应该使用copy，但是没有使用copyif (isShouldUseCopy(typeStr) && !(attrKind & ObjCPropertyAttribute::kind_copy)) {// 通过CI获取诊断引擎DiagnosticsEngine &diag = CI.getDiagnostics();// Report 报告/**错误位置：getLocation 节点位置错误：getCustomDiagID（等级，提示）*/diag.Report(propertyDecl->getLocation(), diag.getCustomDiagID(DiagnosticsEngine::Warning, "%0 - 这个属性推荐使用copy修饰!!"))<< typeStr;}}}};// 第二步：扫描配置完毕// 3、自定义JPASTConsumer，继承自抽象类 ASTConsumer，用于监听AST节点的信息 -- 过滤器class JPASTConsumer : public ASTConsumer {private:// AST 节点查找器（过滤器）MatchFinder matcher;// 回调对象JPMatchCallback callback;public:// 构造方法中创建MatchFinder对象JPASTConsumer(CompilerInstance &CI):callback(CI) { // 构造即将CI传递给callback// 添加一个MatchFinder，每个objcPropertyDecl节点绑定一个objcPropertyDecl标识（去匹配objcPropertyDecl节点）// 回调callback，其实是在CJLMatchCallback里面重写run方法（真正回调的是回调run方法）matcher.addMatcher(objcPropertyDecl().bind("objcPropertyDecl"), &callback);}// 重载两个方法 HandleTopLevelDecl 和 HandleTranslationUnit// 解析完毕一个顶级的声明就回调一次（顶级节点，即全局变量，属性，函数等）bool HandleTopLevelDecl(DeclGroupRef D) {//            cout<<"正在解析..."<<endl;return true;}// 当整个文件都解析完毕后回调void HandleTranslationUnit(ASTContext &Ctx) {//            cout<<"文件解析完毕！！！"<<endl;// 将文件解析完毕后的上下文context（即AST语法树） 给 matchermatcher.matchAST(Ctx);}};//2、继承PluginASTAction，实现我们自定义的JPASTAction，即自定义AST语法树行为class JPASTAction : public PluginASTAction {public:// 重载ParseArgs 和 CreateASTConsumer方法/*解析给定的插件命令行参数- param CI 编译器实例，用于报告诊断。- return 如果解析成功，则为true；否则，插件将被销毁，并且不执行任何操作。该插件负责使用CompilerInstance的Diagnostic对象报告错误。*/bool ParseArgs(const CompilerInstance &CI, const std::vector<std::string> &arg) {return true;}// 返回自定义的JPASTConsumer对象，抽象类ASTConsumer的子类unique_ptr<ASTConsumer> CreateASTConsumer(CompilerInstance &CI, StringRef InFile) {/**传递CICI用于：- 判断文件是否是用户的- 抛出警告*/return unique_ptr<JPASTConsumer>(new JPASTConsumer(CI));}};
}// 第一步：注册插件，并自定义JPASTAction类// 1、注册插件
static FrontendPluginRegistry::Add<JPPlugin::JPASTAction> X("JPPlugin", "this is JPPlugin");

3.1 终端测试插件

新建立一个工程，在ViewController.m里面写入如下代码

@interface ViewController ()@property (nonatomic , strong) NSString *name;
@property (nonatomic , strong) NSArray *array;@end
  • 测试命令 如下

“ 自己编译的 clang文件路径 -isysroot 模拟器文件路径 -Xclang -load -Xclang插件路径(.dylib) -Xclang -add-plugin -Xclang 插件名字 -c 源码文件路径 ”

  • 自己编译的 clang文件路径为：llvm-project/llvm_build/Debug/bin/clang