LLVM 简介
一、什么是 LLVM?
- LLVM 是构架编译器(compiler)的框架系统,以 C++ 编写而成,用于优化以任意程序语言编写的程序的编译时间(compile-time)、链接时间(link-time)、运行时间(runtime)以及空闲时间(idle-time),对开发者保持开放,并兼容已有脚本。
- LLVM 最早的时候是 Illinois 的一个研究项目,主要负责人是 Chris Lattner,他现在就职于Apple。Apple 目前也是 LLVM 项目的主要赞助者之一。
- 在理解 LLVM 时,我们可以认为它包括了一个狭义的 LLVM 和一个广义的 LLVM。广义的 LLVM 其实就是指整个 LLVM 编译器架构,包括了前端、后端、优化器、众多的库函数以及很多的模块;而狭义的 LLVM 其实就是聚焦于编译器后端功能(代码生成、代码优化、JIT等)的一系列模块和库。
二、传统编译器设计
- 传统编译器分三个阶段: 前端(Frontend)-> 优化器(Optimizer)-> 后端(Backend);
- 前端Frontend:负责分析源代码,可以检查语法级错误(包括词法分析、语法分析、语义分析),并构建针对语言的抽象语法树(AST:Abstract Syntax Tree);抽象语法树可以进一步转换为优化,最终转为新的表示方式,然后再交给让优化器和后端处理,LLVM 的前端还会生成中间代码(intermediate representation,简称IR);最终由后端生成可执行的机器码(可以理解为 LLVM 是编译器 + 优化器, 接收的是 IR 中间代码,输出的还是 IR,给后端,经过后端翻译成目标指令集);
- 优化器 Optimizer:优化器负责进行各种优化,改善代码的运行时间,例如消除冗余计算等;
- 后端 Backend(代码生成器 Code Generator):将代码映射到目标指令集,生成机器代码,并且进行机器代码相关的代码优化;
- 源码 Source Code + 前端 Frontend + 优化器 Optimizer + 后端 Backend(代码生成器 CodeGenerator)+ 机器码 Machine Code,如下所示:
- LLVM 的优点在于,中间表示IR代码编写良好,而且不同的前端语言最终都转换成同一种的IR。
三、iOS 的编译器架构
- OC、C、C++ 使用的编译器前端是Clang,Swift是swift,后端都是LLVM,如下图所示:
四、LLVM 的设计
- LLVM 设计的最重要方面是,使用通用的代码表示形式(IR),它是用来在编译器中表示代码的形式,所有 LLVM 可以为任何编程语言独立编写前端,并且可以为任意硬件架构独立编写后端,如下所示:
- LLVM的优点:
- 中间表示IR代码编写良好,而且不同的前端语言最终都转换成统一的中间代码LLVM IR(LLVM Intermediate Representation);
- 如果需要支持一种新的变成语言,那么只需要实现一个新的前端;
- 如果需要支持一种新的硬件设备,那么只需要实现一个新的后端;
- 优化阶段是一个通用的阶段,它只针对统一的LLVM IR,不论是支持新的编程语言,还是支持新的硬件设备,都不需要对优化阶段做修改;
- LLVM现在被座位实现何种静态和运行时编译语言的通用基础结构(GCC家族、Java、.NET、Python、Ruby、Scheme、Haskell、D等);
- 相比之下,GCC的前端和后台没分的太开,前端后端耦合在一起,所以GCC为了支持一门新的语言,或者为了支持一个新的目标平台,就变的特别困难;
五、Clang
- clang 是 LLVM 项目中的一个子项目,它是基于 LLVM 架构图的轻量级编译器,诞生之初是为了替代 GCC,提供更快的编译速度,它是负责 C、C++、OC 语言的编译器,属于整个 LLVM 架构中的编译器前端,对于开发者来说,研究 Clang 可以给我们带来很多好处。
- 相比于 GCC,Clang 具有如下优点:
- 编译速度块:在某平台上,Clang 的编译速度显著的快过 GCC(Debug 模式下编译 OC 速度比 GCC 快 3 倍);
- 占用内存小:Clang 生成的AST所占用的内存是 GCC 的五分之一左右;
- 模块化设计:Clang 采用基于库的模块化设计,易于 IDE 集成及其他用途的重用;
- 诊断信息可读性强:在编译过程中,Clang 创建并保留了大量纤细的元数据;(metadata),有利于调试和错误信息更加友善;
- 设计清晰简单,易于理解,扩展性强。
六、Clang 与 LLVM
LLVM编译流程
一、通过命令打印源码编译阶段
- clang -ccc-print-phases main.m
- 输入文件:找到源文件
± 0: input, “main.m”, objective-c - 预处理阶段:这个过程处理包括宏的替换,头文件的导入
± 1: preprocessor, {0}, objective-c-cpp-output - 编译阶段:进行词法分析、语法分析、检测语法是否正确,最终生成IR
± 2: compiler, {1}, ir - 后端:这里LLVM会通过一个一个的pass去优化,每个pass做一些事情,最终生成汇编代码
± 3: backend, {2}, assembler - 汇编代码生成目标文件
± 4: assembler, {3}, object - 链接:链接需要的动态库和静态库,生成可执行文件
± 5: linker, {4}, image(镜像文件) - 绑定:通过不同的架构,生成对应的可执行文件
6: bind-arch, “x86_64”, {5}, image
- 输入文件:找到源文件
- 新建一个工程,cd 到 main.m 路径,然后执行 clang -ccc-print-phases main.m,结果如下:
yangdw@Kody LLVM % clang -ccc-print-phases main.m
+- 0: input, "main.m", objective-c
+- 1: preprocessor, {0}, objective-c-cpp-output
+- 2: compiler, {1}, ir
+- 3: backend, {2}, assembler
+- 4: assembler, {3}, object
+- 5: linker, {4}, image
6: bind-arch, "x86_64", {5}, image
二、预处理编译阶段
- 在 main.m 中键入以下代码:
int test(int a,int b){
return a + b + 3;
}
int main(int argc, const char * argv[]) {
@autoreleasepool {
int a = test(1, 2);
printf("%d",a);
}
return 0;
}
- 然后执行 clang -E main.m,可以看到,结果如下:
# 9 "main.m" 2
int test(int a,int b){
return a + b + 3;
}
int main(int argc, const char * argv[]) {
@autoreleasepool {
int a = test(1, 2);
printf("%d",a);
}
return 0;
}
- 不难看出,这个阶段主要是处理了包括宏的替换和头文件的导入;
三、编译阶段
① 词法分析
- 预处理完成后就会进行词法分析,这里会把代码切成一个个Token,比如大小括号、等于号还有字符串等。
- 通过如下命令查看词法分析的结果:
clang -fmodules -fsyntax-only -Xclang -dump-tokens main.m
- 执行结果如下:
yangdw@Kody LLVM % clang -fmodules -fsyntax-only -Xclang -dump-tokens main.m
annot_module_include '#import <Foundation/Foundation.h>
int test(int a,int b){
return a + b + 3;
}
int main(int argc, con' Loc=<main.m:8:1>
int 'int' [StartOfLine] Loc=<main.m:10:1>
identifier 'test' [LeadingSpace] Loc=<main.m:10:5>
l_paren '(' Loc=<main.m:10:9>
int 'int' Loc=<main.m:10:10>
identifier 'a' [LeadingSpace] Loc=<main.m:10:14>
comma ',' Loc=<main.m:10:15>
int 'int' Loc=<main.m:10:16>
identifier 'b' [LeadingSpace] Loc=<main.m:10:20>
r_paren ')' Loc=<main.m:10:21>
l_brace '{' Loc=<main.m:10:22>
return 'return' [StartOfLine] [LeadingSpace] Loc=<main.m:11:5>
identifier 'a' [LeadingSpace] Loc=<main.m:11:12>
plus '+' [LeadingSpace] Loc=<main.m:11:14>
identifier 'b' [LeadingSpace] Loc=<main.m:11:16>
plus '+' [LeadingSpace] Loc=<main.m:11:18>
numeric_constant '3' [LeadingSpace] Loc=<main.m:11:20>
- 如果头文件找不到,指定sdk:
clang -isysroot (自己SDK路径) -fmodules -fsyntax-only -Xclang -dump-tokens main.m
clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.1.sdk/ -fmodules -fsyntax-only -Xclang -dump-tokens main.m
② 语法分析
- 词法分析完成后就是语法分析,它的任务是验证语法是否正确,在词法分析的基础上将单词序列组合成各类此法短语,如程序、语句、表达式等,然后将所有节点组成抽象语法树(Abstract Syntax TreeAST),语法分析程序判断程序在结构上是否正确。
- 可以通过下面命令查看语法分析的结果:
clang -fmodules -fsyntax-only -Xclang -ast-dump main.m
- 如果导入头文件找不到,可以指定SDK:
clang -isysroot (自己SDK路径) -fmodules -fsyntax-only -Xclang -ast-dump main.m
clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.1.sdk/ -fmodules -fsyntax-only -Xclang -ast-dump main.m
- 语法分析的结果如下所示:
③ 生成中间代码IR
- 生成中间代码IR,代码生成器(Code Generation)会将语法树自顶向下遍历逐步翻译成LLVM IR;
- 可以通过下面命令可以生成.ll的文本文件,查看IR代码。
clang -S -fobjc-arc -emit-llvm main.m
- OC 代码在这一步会进行 runtime 桥接:property合成、ARC处理等;
- IR 的基本语法:
- @ 全局标识
- % 局部标识
- alloca 开辟空间
- align 内存对齐
- i32 32bit 4个字节
- store 写入内存
- load 读取数据
- call 调用函数
- ret 返回
- 生成的中间代码.ll文件如下:
- 其中,test 函数的参数为:
- IR 文件在OC中是可以进行优化的,一般设置是在target - Build Setting - Optimization Level(优化器等级)中设置。LLVM的优化级别分别是-O0 -O1 -O2 -O3 -Os(第一个是大写英文字母O),下面是带优化的生成中间代码IR的命令:
clang -Os -S -fobjc-arc -emit-llvm main.m -o main.ll
- 优化之后如下所示:
- Xcode7 以后开启 bitcode,苹果会做进一步优化,生成.bc的中间代码,通过优化后的IR代码生成 .bc 代码:
clang -emit-llvm -c main.ll -o main.bc
四、生成汇编代码(后端)
- 通过最终的.bc或者.ll代码生成汇编代码:
clang -S -fobjc-arc main.bc -o main.s
clang -S -fobjc-arc main.ll -o main.s
- 生成汇编代码也可以进行优化:
clang -Os -S -fobjc-arc main.m -o main.s
- 此时生成的main.s文件的格式为汇编代码:
yangdw@Kody LLVM % clang -emit-llvm -c main.ll -o main.bc
yangdw@Kody LLVM % clang -S -fobjc-arc main.bc -o main.s
yangdw@Kody LLVM % clang -Os -S -fobjc-arc main.m -o main.s
yangdw@Kody LLVM % file main.s
main.s: assembler source text, ASCII text
五、生成目标文件(编译器)
- 目标文件的生成,是汇编器以汇编代码作为插入,将汇编代码转换为机器代码,最后输出目标文件(object file)
clang -fmodules -c main.s -o main.o
- 可以通过 nm 命令,查看下 main.o 中的符号:
$xcrun nm -nm main.o
- 以下是 main.o 中的符号,其文件格式为目标文件:
yangdw@Kody LLVM % clang -fmodules -c main.s -o main.o
yangdw@Kody LLVM % $xcrun nm -nm main.o
(undefined) external _objc_autoreleasePoolPop
(undefined) external _objc_autoreleasePoolPush
(undefined) external _printf
0000000000000000 (__TEXT,__text) external _test
000000000000000a (__TEXT,__text) external _main
yangdw@Kody LLVM % file main.o
main.o: Mach-O 64-bit object x86_64
- 分析说明:
- _printf 函数是一个是undefined 、external 的
- undefined 表示在当前文件暂时找不到符号_printf
- external 表示这个符号是外部可以访问的
六、链接
- 链接主要是链接需要的动态库和静态库,生成可执行文件,其中
- 静态库会和可执行文件合并;
- 动态库是独立的;
- 连接器把编译生成的 .o 文件和 .dyld .a 文件链接,生成一个mach-o文件:
clang main.o -o main
- 查看链接之后的符号:
$xcrun nm -nm main
- 其中的undefined表示会在运行时进行动态绑定:
clang main.o -o main
$xcrun nm -nm main
(undefined) external _printf(from libSystem)
(undefined) external dyld_stub_binder(from libSystem)
0000000100000000 (__TEXT,__text)[referenced dynamically] external __execute_header
0000000100003f20 (__TEXT,__text) external _test
0000000100003f40 (__TEXT,__text) external _main
0000000100008008 (__DATA,__data) non_external _dyld_private
- 查看 main 是什么格式,此时是 mach-o可执行文件:
yangdw@Kody LLVM % file main
main:Mach-O 64-bit executable x86_64
七、绑定
绑定主要是通过不同的架构,生成对应的mach-o格式可执行文件
八、LLVM 的编译流程如下
Clang插件开发
一、LLVM 下载
- 由于国内网络限制,需要借助镜像下载 LLVM 的源码:LLVM 的镜像链接
- 下载 LLVM 项目:
git clone https://github.com/llvm/llvm-project.git
或者
git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/llvm.git
- 在 LLVM 的 tools 目录下下载 Clang:
cd llvm/tools
git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/clang.git
- 在 LLVM 的 projects 目录下下载 compiler-rt、libcxx、libcxxabi:
cd ../projects
git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/compiler-rt.g
it
git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/libcxx.git
git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/libcxxabi.git
- 在 Clang 的 tools 下安装 extra 工具:
cd ../tools/clang/tools
git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/clang-tools-extra.git
二、LLVM 编译
由于最新的 LLVM 只支持 cmake 来编译,所以需要安装 cmake。
① 安装 cmake
- 查看brew是否安装cmake,如果已经安装,则跳过下面步骤:
brew list
- 通过 brew 安装 cmake:
brew install cmake
② 通过 Xcode 编译 LLVM
- cmake 编译成 Xcode 项目:
// 在llvm同级目录下新建一个build_xcode文件
mkdir build_xcode
cd build_xcode
// 编译llvm
cmake -G Xcode ../llvm
- 如果编译过程中遇到如下的错误:删除构建目录下的 CMakeCache.txt 即可。
CMake Error: Error: generator : Xcode
Does not match the generator used previously: Ninja
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
- 使用 Xcode 编译 Clang,选择自动创建 Schemes:
- 编译(CMD + B),选择 ALL_BUILD Secheme 进行编译(时间较长,预计一个小时以上)
- 如果编译过程中遇到错误:error: The i386 architecture is deprecated. You should update your ARCHS build setting to remove the i386 architecture。
只需要将对应中的 Build Settings 选项 Architectures 中的值切换为 Standard Architectures(64-bit Intel) 即可。
或者:选择手动创建Schemes,然后编译编译 Clang + ClangTooling 即可。
③ 通过 ninja 编译 LLVM
- 使用 ninja 进行编译则还需要安装 ninja,使用以下命令安装ninja:
brew install ninja
- 在 LLVM 源码根目录下新建 build_ninja 目录,最终会在 build_ninja 目录下生成build.ninja;
- 在 LLVM 源码根目录下新建 llvm_release 目录,最终编译文件会在 llvm_release 文件夹路径下:
cd llvm_build
// -DCMAKE_INSTALL_PREFIX 指定 LLVM 的安装路径,注意:DCMAKE_INSTALL_PREFIX后面不能有空格
cmake -G Ninja ../llvm -DCMAKE_INSTALL_PREFIX= 安装路径(本机为/ Users/xxx/xxx/LLVM/llvm_release)
- 一次执行编译,安装指令:
ninja
ninja install
三、创建插件
- 在 /llvm/tools/clang/tools 目录下新建插件 YDWPlugin:
- 在 /llvm/tools/clang/tools 目录下的 CMakeLists.txt 文件,新增add_clang_subdirectory(YDWPlugin),此处的 YDWPlugin 即为上一步创建的插件名称;
- 在 YDWPlugin 目录下新建两个文件,分别是 YDWPlugi.cpp 和 CMakeLists.txt,并在CMakeLists.txt 中加上以下代码:
// 通过终端在YDWPlugin目录下创建
touch YDWPlugin.cpp
touch CMakeLists.txt
// CMakeLists.txt中添加以下代码
add_llvm_library(YDWPlugin MODULE BUILDTREE_ONLY
YDWPlugin.cpp
)
- 利用 cmake 重新生成 Xcode 项目,在 build_xcode 目录下执行以下命令:
cmake -G Xcode ../llvm
- 最后可以在 LLVM 的 Xcode 项目中可以看到 Loadable modules 目录下由自定义的YDWPlugin 目录,然后就可以在里面编写相应的插件代码。
四、编写插件代码
- 在 YDWPlugin 目录下的 YDWPlugin.cpp 文件中,加入以下代码:
// create by YDW
// 2020/11/25
#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 YDWPlugin {
//第三步:扫描完毕的回调函数
//4、自定义回调类,继承自MatchCallback
class YDWMatchCallback: public MatchFinder::MatchCallback {
private:
//CI传递路径:YDWASTAction类中的CreateASTConsumer方法参数 - YDWConsumer的构造函数 - YDWMatchCallback的私有属性,通过构造函数从YDWASTConsumer构造函数中获取
CompilerInstance &CI;
//判断是否是用户源文件
bool isUserSourceCode(const string filename) {
//文件名不为空
if (filename.empty()) return false;
//非xcode中的源码都认为是用户的
if (filename.find("/Applications/Xcode.app/") == 0) return false;
return true;
}
//判断是否应该用copy修饰
bool isShouldUseCopy(const string typeStr) {
//判断类型是否是NSString | NSArray | NSDictionary
if (typeStr.find("NSString") != string::npos ||
typeStr.find("NSArray") != string::npos ||
typeStr.find("NSDictionary") != string::npos/*...*/)
{
return true;
}
return false;
}
public:
YDWMatchCallback(CompilerInstance &CI) :CI(CI) {}
//重写run方法
void run(const MatchFinder::MatchResult &Result) {
//通过result获取到相关节点 -- 根据节点标记获取(标记需要与YDWASTConsumer构造方法中一致)
const ObjCPropertyDecl *propertyDecl = Result.Nodes.getNodeAs<ObjCPropertyDecl>("objcPropertyDecl");
//判断节点有值,并且是用户文件
if (propertyDecl && isUserSourceCode(CI.getSourceManager().getFilename(propertyDecl->getSourceRange().getBegin()).str()) ) {
//15、获取节点的描述信息
ObjCPropertyDecl::PropertyAttributeKind attrKind = propertyDecl->getPropertyAttributes();
//获取节点的类型,并转成字符串
string typeStr = propertyDecl->getType().getAsString();
// cout<<"---------拿到了:"<<typeStr<<"---------"<<endl;
//判断应该使用copy,但是没有使用copy
if (propertyDecl->getTypeSourceInfo() && isShouldUseCopy(typeStr) && !(attrKind & ObjCPropertyDecl::OBJC_PR_copy)) {
//使用CI发警告信息
//通过CI获取诊断引擎
DiagnosticsEngine &diag = CI.getDiagnostics();
//通过诊断引擎 report报告 错误,即抛出异常
/*
错误位置:getBeginLoc 节点开始位置
错误:getCustomDiagID(等级,提示)
*/
diag.Report(propertyDecl->getBeginLoc(), diag.getCustomDiagID(DiagnosticsEngine::Warning, "%0 - 这个地方推荐使用copy!!"))<< typeStr;
}
}
}
};
//第二步:扫描配置完毕
//3、自定义YDWASTConsumer,继承自ASTConsumer,用于监听AST节点的信息 -- 过滤器
class YDWASTConsumer: public ASTConsumer {
private:
//AST节点的查找过滤器
MatchFinder matcher;
//定义回调类对象
YDWMatchCallback callback;
public:
//构造方法中创建matcherFinder对象
YDWASTConsumer(CompilerInstance &CI) : callback(CI) {
//添加一个MatchFinder,每个objcPropertyDecl节点绑定一个objcPropertyDecl标识(去匹配objcPropertyDecl节点)
//回调callback,其实是在YDWMatchCallback里面重写run方法(真正回调的是回调run方法)
matcher.addMatcher(objcPropertyDecl().bind("objcPropertyDecl"), &callback);
}
//实现两个回调方法 HandleTopLevelDecl 和 HandleTranslationUnit
//解析完一个顶级的声明,就回调一次(顶级节点,相当于一个全局变量、函数声明)
bool HandleTopLevelDecl(DeclGroupRef D){
// cout<<"正在解析..."<<endl;
return true;
}
//整个文件都解析完成的回调
void HandleTranslationUnit(ASTContext &context) {
// cout<<"文件解析完毕!"<<endl;
//将文件解析完毕后的上下文context(即AST语法树) 给 matcher
matcher.matchAST(context);
}
};
//2、继承PluginASTAction,实现我们自定义的Action,即自定义AST语法树行为
class YDWASTAction: public PluginASTAction {
public:
//重载ParseArgs 和 CreateASTConsumer方法
bool ParseArgs(const CompilerInstance &ci, const std::vector<std::string> &args) {
return true;
}
//返回ASTConsumer类型对象,其中ASTConsumer是一个抽象类,即基类
/*
解析给定的插件命令行参数。
- param CI 编译器实例,用于报告诊断。
- return 如果解析成功,则为true;否则,插件将被销毁,并且不执行任何操作。该插件负责使用CompilerInstance的Diagnostic对象报告错误。
*/
unique_ptr<ASTConsumer> CreateASTConsumer(CompilerInstance &CI, StringRef iFile) {
//返回自定义的YDWASTConsumer,即ASTConsumer的子类对象
/*
CI用于:
- 判断文件是否使用户的
- 抛出警告
*/
return unique_ptr<YDWASTConsumer> (new YDWASTConsumer(CI));
}
};
}
// 第一步:注册插件,并自定义AST语法树Action类
// 1、注册插件
static FrontendPluginRegistry::Add<YDWPlugin::YDWASTAction> YDW("YDWPlugin", "This is YDWPlugin");
- 原理分析:
- ① 注册插件,并自定义AST语法树Action类
- 继承自 PluginASTAction,自定义 ASTAction,需要重载两个方法 ParseArgs 和 CreateASTConsumer,其中的重点方法是 CreateASTConsumer,方法中有个参数 CI 即编译实例对象,主要用于判断文件是否是属于用户和抛出警告;
- 通过 FrontendPluginRegistry 注册插件,需要关联插件名与自定义的 ASTAction 类;
- ② 扫描配置完毕
- 继承自 ASTConsumer 类,实现自定义的子类 YDWASTConsumer,有两个参数 MatchFinder 对象 matcher 以及 YDWMatchCallback 自定义的回调对象 callback;
- 实现构造函数,主要是创建 MatchFinder 对象,以及将 CI 传递给回调对象;
- 实现两个回调方法:HandleTopLevelDecl:解析完一个顶级的声明,就回调一次;
HandleTranslationUnit:整个文件都解析完成的回调,将文件解析完毕后的上下文context(即AST语法树) 给 matcher;
- ③ 扫描完毕的回调函数
- 继承自 MatchFinder::MatchCallback,自定义回调类 YDWMatchCallback;
- 定义 CompilerInstance 私有属性,用于接收 ASTConsumer 类传递过来的 CI 信息;
- 重写 run 方法:
- 通过 result,根据节点标记,获取相应节点,此时的标记需要与 YDWASTConsumer 构造方法中一致;
- 判断节点有值,并且是用户文件即 isUserSourceCode 私有方法;
- 获取节点的描述信息;
- 获取节点的类型,并转成字符串;
- 判断应该使用 copy,但是没有使用 copy;
- 通过 CI 获取诊断引擎;
- 通过诊断引擎报告错误;
- ① 注册插件,并自定义AST语法树Action类
五、测试插件
- 在终端中测试插件:
// 命令格式
自己编译的clang文件路径 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.1.sdk/ -Xclang -load -Xclang 插件(.dyld)路径 -Xclang -add-plugin -Xclang 插件名 -c 源码路径
// 举例
/Users/XXX/Desktop/build_xcode/Debug/bin/clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.1.sdk/ -Xclang -load -Xclang /Users/XXXX/Desktop/build_xcode/Debug/lib/YDWPlugin.dylib -Xclang -add-plugin -Xclang YDWPlugin -c /Users/XXXX/Desktop/XXX/XXXX/测试demo/testClang/testClang/ViewController.m
- 结果展示:
/Users/XXX/Desktop/build_xcode/Debug/bin/clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.1.sdk/ -Xclang -load -Xclang /Users/XXXX/Desktop/build_xcode/Debug/lib/YDWPlugin.dylib -Xclang -add-plugin -Xclang YDWPlugin -c /Users/XXXX/Desktop/XXX/XXXX/测试demo/testClang/testClang/ViewController.m
...
Controller.m:12: Warning:
------- NSString* 没用 copy 修饰 --------
@property (nonatomic, strong) NSString *name;
------- NSArray* 没用 copy 修饰 --------
@property (nonatomic, strong) NSArray *list;
...
六、Xcode 集成插件
- 加载插件,打开测试项目,在 target -> Build Settings -> Other C Flags 添加以下内容:
-Xclang -load -Xclang (.dylib)动态库路径 -Xclang -add-plugin -Xclang YDWPlugin
- 设置编译器,由于 Clang 插件需要使用对应的版本去加载,如果版本不一致会导致编译失败,如下所示:
- 在 Build Settings 栏目中新增两项用户定义的设置,分别是 CC 和 CXX;
- CC 对应的是自己编译的 Clang 的绝对路径;
- CXX 对应的是自己编译的 Clang++ 的绝对路径;
- 接下来在 Build Settings 中搜索 index,将 Enable Index-Wihle-Building Functionality 的 Default 改为 NO;
- 最后,重新编译测试项目,会出现下面的效果: