♡性♡感♡红♡名♡在♡线♡要♡饭♡
(〃∀〃) https://afdian.com/a/nmbxd

以及提前写一个 disclaimer: 我满打满算差不多只学了 4 个月的 C++，所以串里一些关于规范相关的东西也不一定对，问就是 https://eel.is/c++draft/ 启动！

/dev/log01

昨天一个 maintainer 在 tg 上私信我：

> Hi, fyi 22nd release will branch next week
> (https://discourse.llvm.org/t/llvm-22-x-will-branch-next-week-tue-13th-jan/89377)
> which means all the patches landed after
> it will be revealed to public only half a
> year later.

感谢他提醒我，虽然因为隔着五个小时的时差导致我收到信息的时候是凌晨，进而导致作息又乱了..

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 也适用这个逻辑：https://godbolt.org/z/heea3fc8s，那代表说这个 check 原来的处理逻辑也是有 bug 的...

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

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

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

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

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

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

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

对了，最近 clang-tidy 有一个没有人认领的 good first issue: https://github.com/llvm/llvm-project/issues/126032

是一些很简单的重命名工作，预计就一晚上的工作量，如果想参与开源但不知道从哪里开始或许可以看看👀

>>No.67822117
这种丢给顶级AI改就行了吧？

>>No.67823372

其实不用顶级 AI 就能改，之前有十几个类似的 Issues，把所有 diff 喂给随便哪个 agent 大概率都能一遍过，但很不幸 against Developer Policy..

https://llvm.org/docs/DeveloperPolicy.html#ai-generated-contributions

> The one exception we reserve is for GitHub issues labelled with the “good first issue” label. These issues are selected by LLVM contributors to help newcomers get familiar with the code base. Thus, it makes no sense to fix them using AI tools. Using AI tools to fix issues labelled as “good first issues” is forbidden.

<del>(虽然感觉哪怕真的用 AI, Reviewer 也不一定能看出来，但真发现了就要被 flag 成 extractive 了: https://github.com/llvm/llvm-project/pull/172220)</del>

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

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

---

八卦一下：G 家的 NotebookLM 实在太好用了，用了它以后读文档/学知识点都轻松了很多；相比之下隔壁 OAI 的 GPT 聊起天来感觉越来越魔怔了（

/dev/log03

考完概率论继续写点：

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

- 把 CUDA 的修复合进去了，然后 clang-tidy 相关的文档与测试点还在等最后的 Review，猜测今天应该能合进去。

这个 PR 的 Review 过程也很抽象，Aaron 因为不确定我修改的正确性拉来了负责 Offloading 和 libc GPU 相关的 Maintainer，然后他又把皮球扔给了 Clang Tooling，但 Clang Tooling 又没有 Maintainer( `_っ´)

扯皮扯得人麻了。

- 修了一个 libc 数学库相关的 Issue，主要的工作量在折腾 bazel 和 CMake（天下苦构建系统久矣！），合的很快。

- 上一篇 /dev/log 里提到的修复刚刚被 Approve 了，准备晚上合进去。

- 帮忙做了不少 Code Review，因为 Clang-tidy 主要的 Maintainer 来国内旅游（避寒）了……

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

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

- 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 都挂了）

llvm版本更迭太快了，好像是半年一版？

>>No.67854722

是，https://llvm.org/ 里有发版周期，基本上半年一个大版本

今天下午两点有软件所主办的 LLVM Tech Meetup：

https://community.riscv.org/e/m29dgj/

报名+参会免费，主题是 RVV 向量化和RISC-V P 扩展及其 LLVM 支持现状简介，在北京的友友感兴趣可以去看看（

/dev/log04

在折腾完内核开发赛（并把剩余参赛队当鱼炸）后进入了摆烂模式，醒着的时候就在 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，有了 Gemini 这个反而成了花力气最少的部分。

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

/dev/log05

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

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

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

然后闲着没事干重新排了一份简历，抱着半玩票的心态投给了 2012，虽然感觉看到我本科都没毕业大概直接就被筛了.. 上次 2012 员工找我聊天的时候问了我年龄，随后直接变成了 "想了解开源社区的项目随时交流"，难绷（

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

虽然最近疯狂摸鱼，但在 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 这个关于文档优化的项目会前端就行。

/dev/log06

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

最近遇到的一个好事是自己成为了 Clang-tidy 的 Maintainer (https://clang.llvm.org/extra/Maintainers.html)，这是我第一次以真实身份在开源社区出道，算是满足了自己的一个小目标。

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

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

它的功能是把 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.

- 修了一个因为没有测试覆盖而导致的 Crash: https://github.com/llvm/llvm-project/pull/180351

这个 PR 也是我开始加强 Clang-tidy 测试覆盖率的主要原因。

- 更新了失效的 HICPP 文档链接: https://github.com/llvm/llvm-project/pull/180525

这个 PR 在社区里引起了一些其他讨论: https://discourse.llvm.org/t/rfc-regarding-the-current-status-of-hicpp-checks/89883/3

目前的共识是：HICPP 的 check 需要先重命名到别的 module 里，然后再考虑要不要直接删掉整个 module.

自己过去的一个 Commit 莫名其妙上了 LLVM Weekly Report: https://llvmweekly.org/issue/630，虽然只有一行 (争取以后做出更酷炫的成果)

---

编译器社区的一些新闻：

- https://discourse.llvm.org/t/rfc-ai-assisted-bazel-fixer-bot/89178/94

社区里吵了很久的 AI Bazel Bot 尘埃落定，还是放行了。

- Clang 22.1.0 发布：
https://releases.llvm.org/22.1.0/tools/clang/docs/ReleaseNotes.html
https://releases.llvm.org/22.1.0/tools/clang/tools/extra/docs/ReleaseNotes.html

- 世界上最流行的 C++ LSP 工具(之一) Clangd 处在爆炸的边缘：https://discourse.llvm.org/t/help-needed-with-clangd-maintenance/89820

支持 clice.io 谢谢喵

- GSoC 2026 如火如荼进行中！

QEMU: 快照快速加载、USB 设备重定向、vhost-user 内存隔离、COCONUT-SVSM 中支持 x86 PCID、SCSI 磁带设备模拟...

LLVM: https://discourse.llvm.org/t/gsoc-2026-projects-proposals-and-other-information/89967

---

生活琐事：

之前提到了给 2012 投简历的事情，由于官网那边完全没回复，所以我直接尝试微信私聊他们员工了，在等了两天后：

> 有的哈，今年岗位三月底开放，流程要届时才能推进了

也许真的有机会？

以防万一还是投了一些其它的公司，例如阿里平头哥和字节，私下聊天时，朋友给了一个抽象的建议：

> 去 mihoyo 搞 infra

虽然我既不懂游戏开发，也不会做 Infra，但我觉得这个想法实在太有乐子了。于是发动 Connection 获得了一个内推码直接投了简历，更抽象的是米哈游写简历的网页上还要写自己的游戏经历，于是:

崩坏星穹铁道 活跃6-12月 已退坑

现在 HR 初筛，期待开奖 (　^ω^)