RSSThe plan fell off.

Mitchell's Homepage Internet's problem child

LLVM 贡献记录

这个文档用来记录我的 LLVM 贡献记录和笔记，大概没什么用，主要是自己看。

本文档是活的文档，会随着我自己的工作进展而更新内容，且不保证已有内容的正确性。

Clang-tidy

cert 重构

学到了有关 Clang-tidy Checks 的取名方式：

we never used "dont" in check name (thought we can use verbs like "avoid" (avoid-goto etc..))

avoid is used when check category is generic like "cppcoreguidelines" or "readabilty". "bugprone" category means by default that we should avoid some language construct.

Check Fixes

学到了关于代码风格的知识：

Clang 的代码库要求贡献者尽可能为变量加上 const

更完整的代码规范在 官网上，不过太长了还没读完。

我 C++ 水平实在是有点次，该读书了。

同时在 Review 过程中，@vbvictor 给了一个我写代码时没想到的 false-positive: link，已严肃学习。

以及 TK_IgnoreUnlessSpelledInSource 和 TK_AsIs 的区别是，前者会忽略编译器隐式生成的节点 (e.g. 默认构造函数、隐式转换)，后者则不会对 AST 做任何过滤。

学习了怎么给 Clang-tidy 的 Check 添加 Option，以后要改/实现类似功能的时候直接翻这个 PR 作参考就行。

LLVM 的 Regex 库真的很好用，本来以为这个 Issue 会修很久，结果一个小时就写完了，接下来就是和 Reviewer 对线，好文明。

2025/11/17 Update:

社区的沟通似乎出现了一些 telemiscommunication, @lakshsidhu04 先前接了这个 Issue 后因为自己的时间问题被 Unassign 了，最后我看没人干就把它做了，但他的 PR 也是开着的，造成了一些 Reviewing 上的阻碍，不过问题不大。

2025/11/19 Update:

感谢 @zwuis (似乎是南科佬?) 的反复提醒，以后要注意 std 库的规范使用。

似乎 Ready to merge :) 合了

比较难绷的是在 clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.h 里有一段神级代码：

static ExceptionInfo createNonThrowing() { return {State::Throwing}; }

有一种左右脑互博的美，遂直接开始对线，不过还没有人回复，静侯结果。

2025/11/19 Update:

我又忘记要 Early return 了，看来必须要为 LLM Reviewer 写 Prompt 了，不然以后天天修代码规范就老实了。

2025/11/28 Update:

文档风格又出问题，不过其它文档也干了，所以我顺手又水了一个 PR

崩溃的原因是 FormatStringConverter::appendFormatText 里用了 signed chars，遇到非 ASCII 字符时就变成负数走到控制字符的路径了，传到 llvm::hexdigit直接 OOB 然后 Crash. 问题简单到没开 GDB 光读代码就理解了。

然后找 Bug 加修 Bug 一共半小时，尝试让 Windows 过 CI 测试花了三天还没修出来，原因是 LLVM 的 Windows CI 不知道 UTF-8 是什么，只认自己的编码逻辑，导致测试点里写 UTF-8 字符直接挂。

这 Windows 怎么 NMD 这么创啊

把能用的不能用的方法都试了一遍，还是过不了，人麻了。

2025/11/26 Update:

开摆了，直接在 Windows 上跳过测试了, We are so done.

2025/11/28 Update:

复活！@localspook 提醒了我可以直接指定 python 脚本的输出编码，果然让 Windows CI 过了! We are so back.

以及进行一些善意引导，我感觉它之前过不了 + 很难复现可能和这个 RFC 有关系，它不会现在还在用 Vista 吧，草。

Zealot 正好抓到了这个 Issue 的更新，顺手修了。

CI 改进

Clang-tidy 在尝试为文档加更多的检查 (句末空格/缺换行/80字限制等)，这一系列的工作记录在 #165999。

所以分成两个部分，一方面是 CI 的具体实现，另一方面是已有文档的修复。

Doc Fixes

此为写 Python 脚本后白送的免费 PR，不可不水。

以及 LLVM 会把一些没什么用的修改加到 .git-blame-ignore-revs 里，这样 git blame 的时候就可以用 --ignore-rev 忽略它们，我之前没有听说过这个技巧 (每日一个 git 小知识了属于是)。

2025/11/19 Update:

这个文件上的 Commits 是按照时间排序的，下次改要注意不要弄错顺序，往文档末尾加。

没什么营养的文档修复，之前对线的时候发现的，顺手的事。

检测脚本

2025/11/15 Update:

@vbvictor 和 @LegalizeAdulthood 回复了，目前差不多确定了这个 RFC 的实现方式：在 LLVM 官网上加一段话（

不过最近没太多时间忙这个，现在当务之急是学 LLVM CI Container 是怎么写的。

2025/11/19 Update:

先 Close 了，有空再看。

通过这个 PR 我才知道 LLVM 的 Python 脚本必须为 3.8 提供支持 (然而这个版本已经 EOL 了)，离了个大谱。

搜了下论坛，发现时不时就有人吵要不要把 Python 版本拉高，例如 Upgrading LLVM’s minimum required Python version 和 RFC: adopt regularly scheduled Python minimum version bumps，好消息是最近他们吵完了，决定拉到 3.10 了，从已经 EOL 到明年 EOL，明年的架明年再吵 (什么猴子马戏团)。

2025/11/19 Update:

这个脚本找出了我自己引入的问题，融入马戏团了属于是。

以及由于我不知道怎么写 Python 代码导致整出了 Tuple[List[str], List[Tuple[str, List[str]]], List[str]] 这种逆天活，从 Review Messages 里学到了用 NamedTuple 和 @dataclass，我唐完了。

2025/11/26 Update:

Approve 了，再等一个 Reviewer Approve 后就可以 Merge 了。

尝试把 doc8 集成到 LLVM 的 CI 里，一边和 Gemini 吵架一边写代码，开了 PR 以后悲剧地发现 Premerge CI 里不会触发新的 Dockerfile 构建，为了先证明这玩意能跑，于是写出了以下逆天内容：


      - name: Install linter dependencies
        run: |
          pip install doc8 --break-system-packages
          echo "$HOME/.local/bin" >> $GITHUB_PATH

可怕吗，是的很可怕

事实证明这玩意确实能跑：


./clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-functions.rst:99: D001 Line too long
./clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-functions.rst:100: D001 Line too long
./clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-functions.rst:105: D001 Line too long
./clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-functions.rst:106: D001 Line too long
./clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-functions.rst:107: D001 Line too long
./clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-functions.rst:111: D001 Line too long
./clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-functions.rst:112: D001 Line too long
./clang-tools-extra/docs/clang-tidy/checks/bugprone/unsafe-functions.rst:126: D001 Line too long

接下来大概是等 @vbvictor 回复，然后把 git diff 也集成进 doc8 的测试，这样就不用每次都检测所有文件了。

2025/11/28 Update:

由于我不会写 Python 导致这个 PATCH 变成了臭不可闻的依托，拼尽全力拆成了两半准备分两次 Review

我这辈子再也不想写 Python 了。

Issues

没复现出来，但告诉了开 Issue 的人可以用 -extra-arg=-v，放两天看看有没有进展。

2025/11/27 Update:

复现了，看上去是因为 -Wno-format-security 和 -Wformat 的顺序错了，先 -Wno-format... 再 -Wformat 会重新打开 security warnings，再加上一个 -Werror 直接变 Warning 炸掉

2025/11/28 Update:

不对，还有反转。怎么 build 情况不报错啊。

现在猜测是用户编译拿的是 gcc，因为 GNU 神人班不管什么参数顺序，关了就是关了，所以没 Warning，但 Clang-tidy 底下还是 Clang，所以有 Warning

考虑了几个很常见的控制/信息流相关的情况，感觉 Clang Tidy 其实不太好做这个 Check (AST 信息很有限)

@vbvictor 提到了一个 PR 实现了相关的一部分逻辑，一看 + 1246 -0 立刻失去了 Review 的动力，等我做好心理准备再去看。

复现不出来，人也不回复，就这样吧。

Clang Static Analyzer

目前只修了一个文档问题，是改 Clang-tidy 那里时发现的：

@NagyDonat 很贴心地补充了 CSA 中这些 Check 的历史背景：

By the way, note that these security.insecureAPI checkers are "out of place" in the analyzer. These were developed a long time ago and they are "grandfathered in" because they are used by the users, but freshly developed simple AST-based checks like this would belong to Clang-Tidy — which is a more lightweight tool and is more accessible for the users. However, this doesn't detract from the value of this documentation patch — documentation is equally valuable for all checkers that we provide.

Clang

投喂可爱 Clang 前端，之前它会输出像 [22/18] 这样的诡异计数，在经过我的修复后，变成了这个更诡异的样子：


[1/9] Processing file ...
[2/9] (1/2) Processing file ...
[2/9] (2/2) Processing file ...
[3/9] Processing file ...
[4/9] Processing file ...

有点闹麻，也不知道能不能合进去。

尝试为 Clang 的新 constexpr 虚拟机和 Legacy 解释器添加一些向量指令的支持，不过还没做完

做完再写。