LLVM 贡献记录

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

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

2026-01-08

clang-22 距离发版还有 5 天，现在手上还有 11 个在做的 PR (💦)，更不幸的是 clang 发版时间和我期末考试还撞一起了，寄完了 (明天考马原，目前一章没学，等下还得去找 pdf 背)

但感觉有几个 PR 或许有机会能压着时间点 land:

一是给 clang-tidy 某个 check 加 C++20 constinit 的支持，这个 PR 目前缺一些测试点和文档上的小修改，感觉今天晚上睡前顺手修掉问题不大

以及在和 Reviewer 对线的过程中发现了一个很有趣 (创) 的事情：

https://clang-tidy.godbolt.org/z/qTbvKs69W

extern int b;
constinit int b = 42;

先 extern 声明再 declare constinit, 最开始的 extern 不会拿到 constinit 的属性! (for anyone interested: 本地复现可以拿 clang -Xclang -ast-dump -fsyntax-only 跑出来，不过这种情况一般会用 clang-query..)

|-VarDecl prev 0x11b00d88 <line:7:1, col:19> col:15 b 'int' cinit
| |-IntegerLiteral <col:19> 'int' 42
| `-ConstInitAttr <col:1> constinit

另一位 maintainer 找出了 constexpr 也适用这个逻辑, 那代表说这个 check 原来的处理逻辑也是有 bug 的…

不管怎么样能定出来的 bug 都是好 bug，至少修起来会比较简单。

给一个 check 加新的 option: 这个 PR 被拖了差不多一个月，但隔壁 cppcheck 和 simplecpp 两个项目已经出现了缺这个 option 导致的问题，但没人 Review 我其实也没什么办法，昨天给了一些代码风格和测试点上的意见，感觉全 address 后应该就差不多了？但感觉会很折磨，这个分支有点太老了，切过去大概要从头开始编译.. 准备等下问问伟大的 Gemini 有没有什么好办法。

一些如果能 land 会很好的 PR:

CUDA support!!: 上周在尝试给 clang-tidy 加 CUDA 支持时，修了一个 Assert Failure 的问题，但 AaronBallman 在过圣诞假期，所以无人来审。

然后前两天一个 Google 的工程师说要给 Tooling 加一套编译信息的框架来解决这个问题，我觉得很难评，主要是我确实不知道 Clang Tooling 和 Clang Driver 是怎么交互的，而如果准备现在把这玩意搞清楚，那我概率论就可以重修去了 (　^ω)

数据流分析的 Regression: 有人找到了一个 False Positive，看上去是 clang19 到 20 之间引入的 regression, 查了两个小时发现是新引入的缓存机制导致原始代码里 Matcher 的一个未知隐蔽 bug 开始发力 (世界上第三痛苦的事是 debug CI，第二痛苦的事是 bisect，最痛苦的事情是一边 bisect 一边写小作文……)

很难受的是虽然 bisect 出了 commit 但还是没方法稳定复现问题，我猜测是 range based loops 的问题，但数据流分析的东西太难手动构造出不收敛且好观测的情况了，直接爆炸。

2026-01-09

考完了马原（烂完），出考场一看昨天修的 PR 被 Approve 了，今天看到了一个关于 private copy constructor 的 False Positive，估算了一下代码量应该很小，打算晚上写个 PATCH 修一下。

顺手 ping 了一下 Aaron，我真的很想在这周以内把 CUDA 相关的两个 PR 合进去，这样 clang-tidy 的 CUDA module 或许能有点实际推进（圣诞节前给 NVIDIA 法务部发了询问邮件，可惜直接被无视了，LLVM Legal Team 也没消息，也不知道去哪里找相关的人问，就拖到现在还没开始动工）

2026-01-13

考完概率论继续写点：

今天理论上就是开 22.x branch 的日子了，总结一下这几天干的事情：

把 CUDA 的修复合进去了，然后 clang-tidy 相关的文档与测试点还在等最后的 Review，猜测今天应该能合进去。
修了一个 libc 数学库相关的 Issue，主要的工作量在折腾 bazel 和 CMake 天下苦构建系统久矣!，合的很快。
上一篇 /dev/log 里提到的修复刚刚被 Approve 了，准备晚上合进去。
帮忙做了不少 Code Review

总体上来说效率不是很高，主要是期末周/比赛答辩/项目发版全部撞在一周以内还是太变态了，完全处理不过来，有心无力了属于是。

同时这几天编译器社区出了不少新闻，来点简单分享：

LLVM Lead Maintainer 炮打 LLVM：https://www.npopov.com/2026/01/11/LLVM-The-bad-parts.html
2026 EuroLLVM 截稿：https://discourse.llvm.org/t/call-for-proposals-2026-eurollvm-developers-meeting-submit-by-11-january/89336)
GCC 16.0 进 Stage 4 了，距离正式发布越来越近了(・ω・)
GCC 发布了 Sourceware infrastructure updates for Q4 2025，分享过去三个月 GCC 在 Infra 上的改进 LLVM 什么时候能学学 GCC，我基本就没怎么见 bazel, openmp, polly 这几个模块的 CI 正常跑通，今天甚至连 ABI 的 CI 都挂了

2026-01-23

在折腾完内核开发赛 ~~(并把剩余参赛队当鱼炸)~~ 后进入了摆烂模式，醒着的时候就在 Minecraft 启动，昨天又开始拉电线坐牢，感觉这破游戏玩不下去一点。

期末周计算机网络和概率论的一天速通非常成功，两门一点都没学的课居然都没挂，喜提 3.3，感谢老师不杀之恩 ( ´∀`)

LLVM 这里有一点产出，但不多：

修了一个和宏相关的 assertion failure 问题。
修了一个 parenthesized functions 的错误 fixits。
把之前 Clang-tidy 中 CUDA 相关的文档给合进去了，新的文档可以在这里看：https://clang.llvm.org/extra/clang-tidy/#running-clang-tidy-on-cuda-files
doc8 配置更新：在 Google 两位工程师 (Florian Mayer 和 Rohan Jacob-Rao) 的清理后，clang-tidy 的 doc8 配置终于不需要各种奇怪的 hack 了，好事。
尝试修了下 check_clang_tidy.py，这个 python 脚本居然不支持检查头文件，这个缺失功能就这么放了一年，简直离谱！所以趁有时间就顺手修掉了，不过现在还没有足够的 Reviewer 来审。唉，Reviewing Bandwith.
修了一个 21.1.8 下的 False Positive，不过现在还没什么人来审。鬼故事：在修这个 FP 的时候又发现了一个新的 FP：https://clang-tidy.godbolt.org/z/e8eMav36f
有一个没有及时合并的修复需要重新拉进 22.x 的分支里，借这个机会学习了一下怎么给 LLVM 合进主线的 Commits 做 backport，只需要在评论区输入 /cherry-pick <hash> 就可以了，感觉很方便。
每日两到三个 Code Review，这个反而成了花力气最少的部分。

这个月其他的也不想干了，剩下时间就继续拉电线了。这辈子彻底有了，哈哈

2026-02-04

做手术前再来💧一篇开发日志，虽然这十天其实也没干什么|ー` )

首先，在卡池里经历了漫长的折磨后，我卸载了拉电线神游。

不打游戏省出来的时间主要在忙着重构博客 ~~抄明日方舟的设计~~，拼尽全力糊出来一个能跑的玩意: https://broken.life/ (建议用电脑/平板，我前端能力一坨，手机端不知道怎么做适配直接摆了)

实验室的项目目前进展也不太良好，上次和导师开完小会给完方案后就躺了，打算手术后看看怎么实现，寄。

虽然最近疯狂摸鱼，但在 LLVM 里也还是做了一些事情：

修了下 bugprone-macro-parentheses 的诊断信息

虽然 clang-tidy 不应该诊断命令行的参数，但这个 check 添加支持很简单，那顺手修了也挺好。

修了下 performance-enum-size 对 extern “C” 的一些错误分析，日常改 Matcher..
为 readability-non-const-parameter 加了一些 corner case 的支持
修了一个有 bug 的 python 脚本，顺带给文档和 list.rst 打了个补丁

之前在 Review 其他 PR 时，在 list.rst 里时不时就能发现一些很奇怪的修改，原先以为是 PR 作者在 Merging 的时候出了问题，后面发现好像并不是。添加 check 的脚本对代码库做了一些不完全正确的假设，导致重新生成内容的时候搞乱了整个排序。

给 MLIR 修了一个 arith.select 相关的 crash，这个 PATCH 没什么技术含量
修了 clang-tidy 代码库里的 unchecked-optional-access 警告，之前已经遇到过因为这些警告而导致程序崩溃的例子了，故干脆一起修了。
每日 3-4 个 PR Review，感觉已经快成 daily routine 了

今天凌晨另一位国内的 Contributor 私信我了一个 RFC：https://discourse.llvm.org/t/rfc-remove-80-column-limit-in-documentation-files/89678，很不幸的是 clang-tidy 文档相关的 CI 是我搓的，那后面还得更进一下这个 RFC 的进展，可能还要改配置，但已有的文档怎么处理就不知道了

以及 GSoC 2026 要开始了，LLVM 相关的 Project 已经可以在 https://discourse.llvm.org/tag/gsoc2026 看到了，GCC 相关的讨论目前似乎还只是在邮件列表里，三月份应该会公开具体信息。

完成项目的话应该能拿几千美刀和一个 Google 发的证书，感兴趣可以看看，不一定要有很强的编译器相关背景，例如：https://discourse.llvm.org/t/gsoc-2026-improving-clang-doc/89662 这个关于文档优化的项目会前端就行。

2026-03-07

由于寒假忙着做手术和打游戏，导致没有写开发日志，开学了补上。

最近遇到的一个好事是自己成为了 Clang-tidy 的 Maintainer (https://clang.llvm.org/extra/Maintainers.html)

这是我第一次以真实身份在开源社区出道，算是满足了自己的一个小目标。

同时过去的一个月也做了不少事情：

首先，我的个人项目 CTIT (https://github.com/clang-tidy-infra/CTIT) 完成了初步的开发，且已经被用上了。

它的功能是把 PR 的修改自动 apply 到 clang-tidy 的 codebase 上并编译，然后在大型开源项目（如 cppcheck, clang, curl）上运行来检测运行时崩溃、功能退化及误报变化，我还在里面塞了一个小的 AI Agent 来对 Logs 做自动分析。

LLVM 上的一些 PATCH 总结： - 更新了一下 Clang-tidy 的文档，提醒 check authors 在写测试的时候要指定具体的语言 standards (https://github.com/llvm/llvm-project/pull/184750)

简单来说就是没有特殊情况写 -std=c..-or-later

修了 misc-throw-by-value-catch-by-reference 里两个完全失效的 Options (https://github.com/llvm/llvm-project/pull/184750)

非常诡异，这种代码是怎么进到仓库里的，之前的 Reviewer 在审什么东西.

两个补测试覆盖率的 NFC Patches (https://github.com/llvm/llvm-project/pull/184015 和 https://github.com/llvm/llvm-project/pull/184708)
修复了一个和 Attributes 相关的问题 (https://github.com/llvm/llvm-project/pull/184095)

第一次知道原来 Clang 的 Frontend 会把多个连续的 AttributedStmt 压缩成一个

给一个 check 加上了部分缺失的重载 (https://github.com/llvm/llvm-project/pull/183300)

我感觉 Clang-tidy 有很多类似的问题，不知道有没有办法根据标准库的函数声明来做针对性的自动化测试。

修了一个 readability-container-size-empty 中的 Assert Crash (https://github.com/llvm/llvm-project/pull/181557)

getName() 前不做 Sanity check 是坏文明，虽然我自己有时候也会写出这样不好的代码…

一个会影响 Clang-tidy 的 Clang Issue: https://github.com/llvm/llvm-project/pull/181712

Aaron 的评论让我学到了很多架构设计上的新知识:

SDiagsWriter is a subclass of DiagnosticConsumer which defines the contract for finish(). So this means some subclasses will automagically handle finish() while others won’t. WDYT about calling finish() explicitly in tooling? That means any diagnostic consumer will behave correctly, not just serialized diagnostics.