rustc代码全部转为C代码，46百万行C程序能编译Rust

背景

Rust 作为现代系统编程语言，在性能、安全性和并发性上表现出色，但长期以来在目标平台支持上存在明显短板。许多老旧或边缘硬件缺乏 Rust 官方 Rustc、GCC 或 LLVM 的原生支持，开发者和项目方常将此视为使用 Rust 的主要障碍之一。作者在过去三年内多次尝试 Rust 转 C 编译，形成了第 14 次公开尝试——cilly 项目。这次尝试不再依赖 LLVM，而是彻底将 Rustc 转换为纯 C 代码（嵌入少量 C++ LLVM 包装），并通过适配特定 C 编译器实现跨平台。

核心内容

cilly 是一个 Rust 库，用于生成 C 代码，同时作为 Rust 编译器的后端插件（backend），允许用户直接将 Rust 源代码编译为 C 目标代码。它不依赖预构建的 LLVM，而是通过生成“见证程序”（witness programs）查询目标 C 编译器和平台支持的特性，例如：

/* 这个程序仅在 C 编译器支持 _Thread_local 时通过编译。 */
_Thread_local int KEYWORD_TLS_SUPPORTED;

此类机制让 cilly 为“怪异但尚存”的“Shminky C 编译器”生成兼容代码，并对类型布局、大小、对齐、字符编码（ASCII）、整数格式（二补码）进行全面查询，并在可能时提供回退方案。作者强调严格遵守 ANSI C，不做现代 C 标准假设（如严格别名），因此输出结果是编译器和平台高度相关的——arm64 上的 cilly C 无法直接在 riscv32 上运行，必须为每个目标单独生成。

该项目的主要目标是支持缺乏 LLVM/GCC 支持的旧硬件或无 Rust 支持的平台。例如，当项目从 Rust 迁移到 C，或 C 项目需要 Rust 替代方案时，Rust 的跨平台短板常被提及；cilly 则通过包装 rustc 自身、C 编译器和网络（TCP，甚至可扩展到 UART）在不同平台间传输任务，解决引导悖论（bootstrap paradox）问题。作者已在 x86 Plan9 虚拟机上成功编译小型 Rust 程序（使用 arm64 Linux 上的 rustc 通过网络传递），示例输出包括：

term% echo `{cat /dev/sysname} osversion `{cat /dev/osversion} cputype $cputype
gnot osversion 2000 cputype 386
term% /tmp/hello_plan9
Hello, world!
term% nm /tmp/hello_plan9 | grep rust_begin_unwind
1020 T _RNvCshfEkAwg4zv6_7___rustc17rust_begin_unwind

cilly 可在生成的 C 代码中嵌入标记，将 IR 缓存到目录中，并通过 split 函数/全局变量生成 makefile 结构，允许直接用标准 C 编译器和 GNU make 构建 Rust 项目。生成的代码与标准 rustc 编译出的二进制“大部分”ABI 兼容（arm64 上因 sret 结构返回指针问题存在部分差异）。构建 demo 时，需要指定 LLVM 库路径（通过 rustup nightly-2026-06-16-aarch64-unknown-linux-gnu/lib 提供），并使用现代 GCC + GNU make 运行：

make -j20 LLVM_LIB_DIR=~/.rustup/toolchains/nightly-2026-06-16-aarch64-unknown-linux-gnu/lib CFLAGS=-g

无优化时构建时间约 1 分 18 秒；启用优化可能导致大文件编译失败。最终 rustc 版本为 1.98.0-nightly（c712ea946 2026-06-16），支持编译 core、alloc、std 等标准库。作者提及部分路径解析问题（在项目根目录下可能崩溃），且项目仍处于早期阶段，未准备公开使用，但已能自举编译自身 Rust 编译器。

关键要点

• cilly 是第 14 次 Rust 转 C 编译尝试，核心创新在于通过 ANSI C 见证程序动态适配 C 编译器，而非硬编码 LLVM 依赖。
• 输出为编译器/平台特定代码，arm64 目标无法在 riscv32 上直接运行，必须单独生成。
• 支持网络传输（TCP），可解决跨平台引导难题，已在 Plan9 VM 上成功编译小型 Rust 程序。
• 生成的 C 代码部分支持 makefile 构建，可嵌入标记并缓存 IR，实现“用标准 C 编译器+make 构建 Rust”模式。
• 目标是填补缺乏 LLVM/GCC 支持的旧硬件空白，解决“Rust 不支持 Plan9”等常见反对意见。
• 目前仍为 demo 阶段，未公开，作者因工作、大学和个人伤情（左手被绞碎）暂缓推进，但强调尽快发布。

意义与影响

cilly 项目代表了 Rust 生态对极端跨平台需求的另一种探索路径：它不再寄希望于 LLVM 作为通用后端，而是彻底“降级”到 C 层面，最大化兼容老旧或闭源 C 环境。这在支持嵌入式、工业控制、无官方 Rust 工具链的硬件上有现实价值，能让项目方无需等待 Rust 原生支持就迁移或移植代码。对于计划 9 等 niche 系统，证明了 Rust 并非不可触及的壁垒——只需通过网络或 makefile 即可自举。对于开发者而言，这降低了“Rust 生态孤岛”的门槛，尤其在追求极致稳定性的场合。长远看，它可能启发更通用的“语言中立”编译后端设计，但当前版本仍依赖特定 C 编译器和手动 LLVM 路径，需进一步成熟才能替代标准 rustc。总体而言，cilly 证明了“用 C 编译器构建 Rust”并非不可能，而是通过严谨的特性探测和网络传输实现的创新解法，为 Rust 的全球普及提供了可补充的备选方案。