一句话看懂：开发者FractalFir用自研工具链“cilly”，将完整的Rust编译器rustc（46 million行代码）翻译成了C语言，并成功用GCC和make重新编译出一个功能正常的Rust编译器。这个项目不是为了炫技，而是为了解决Rust在老旧或罕见硬件上无法运行的问题——只要这些平台支持C编译器。
事件核心：发生了什么
FractalFir在GitHub上开源了crustc项目，展示了一个“Rust→C编译器”工具链cilly的成果。它把rustc 1.98.0-nightly（Arm64 Linux）翻译成了46 million行C代码，然后用GCC 13.3.0和make成功编译并运行，输出版本号一致，并且能正常编译core、alloc、std等核心库。这已经是cilly的第14次迭代，作者此前还做过rustc_codegen_clr等尝试。
为什么重要
Rust目前依赖LLVM或GCC作为编译器后端，但很多嵌入式、工业控制、复古硬件（如Z80、Plan9）并不支持LLVM或现代GCC后端，只支持特定的C编译器（如SDCC、古老的ANSI C编译器）。cilly通过生成“与C编译器协商”的代码——先编写“见证程序”检测目标平台支持哪些特性（如_Thread_local、类型宽度、字节序）——再根据结果生成兼容的C代码。这意味着：只要目标平台能运行任何ANSI C编译器，就能间接运行Rust代码。这直接回应了“Rust不支持老旧平台”的长期痛点，可能拓宽Rust的生态边界。
对用户/开发者/创作者的影响
对嵌入式、国产芯片、古董硬件开发者：这是潜在的“救星”。如果你维护一个只有C编译器（如SDCC、c89-only的交叉编译器）的硬件平台（如MSP430、Z180），未来可能无需移植LLVM后端，直接用cilly编译Rust代码到C，再用平台原生C编译器完成最终构建。cilly还支持网络透明编译——在一台现代Linux上运行rustc，通过TCP/UART与另一端的C编译器通信，可直接为目标机生成可执行文件。
对普通Rust开发者：短期影响有限。该项目目前生成的C代码是编译器特定的（Arm64版本不能在riscv32上直接用），并且依赖LLVM运行时，属于实验性方案。但一旦工具链成熟，Rust项目在README里声明“支持所有包含C编译器平台”会成为现实。
对工具链开发者：cilly采用的“自协商类型布局”思路值得借鉴，它避免了写死ABI，而是动态探测，这为跨平台代码生成提供了一种新范式。
值得关注的后续
- 工具链稳定性与效率：目前cilly生成的C代码需要LLVM运行时依赖，作者并未打包预编译LLVM。未来是否会集成轻量LLVM分发或让用户自备libLLVM，将影响使用门槛。
- 目标平台扩展：开发者已成功为x86 Plan9 VM编译Rust程序。下一步能否支持更广泛的老旧或嵌入式平台（如MIPS、RISC-V考古版本）将决定该项目的实际覆盖面。
- Rust生态接纳程度：类似于
mrustc（Rust自举编译器），cilly如果被Rust官方或大项目（如embedded-hal）认可，可能成为官方推荐的异构平台构建方案。目前它仍是个人项目，需要社区贡献和测试。
