回应模式 - No.67821632


No.67821632 - 技术宅


无标题无名氏No.67821632 只看PO

2026-01-08(四)15:20:10 ID:vslNeW2 回应

一个并不是从零开始的 llvm 开发日志

编译器开发什么的真是令人头大|ー` )

之前在博客写了不少开发日志,不过由于更新网站要开电脑跑 awk 脚本,并不是很方便,所以准备在这里开个串做一点简单记录 (`・ω・)

Tips无名氏No.9999999

2099-01-01 00:00:01 ID: Tips

(`ε´ )说了多少遍了,这里是婆罗门宅向论坛

无标题无名氏No.67821637

2026-01-08(四)15:21:38 ID: vslNeW2 (PO主)

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

无标题无名氏No.67821891

2026-01-08(四)15:56:27 ID: vslNeW2 (PO主)

/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 的问题,但数据流分析的东西太难手动构造出不收敛且好观测的情况了,直接爆炸。

无标题无名氏No.67822117

2026-01-08(四)16:21:12 ID: vslNeW2 (PO主)

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

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

无标题无名氏No.67823372

2026-01-08(四)19:44:55 ID: 5OiFZ7z

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

无标题无名氏No.67824276

2026-01-08(四)21:13:21 ID: vslNeW2 (PO主)

>>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>

无标题无名氏No.67830251

2026-01-09(五)18:01:57 ID: vslNeW2 (PO主)

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

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

---

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

无标题无名氏No.67854644

2026-01-13(二)13:16:37 ID: vslNeW2 (PO主)

/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 都挂了)

无标题无名氏No.67854722

2026-01-13(二)13:34:29 ID: 4b4Kyvy

llvm版本更迭太快了,好像是半年一版?

无标题无名氏No.67856629

2026-01-13(二)17:14:18 ID: vslNeW2 (PO主)

>>No.67854722

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