LWN：gccrs开发进展！

关注了就能看到更多这么棒的文章哦～

An update on gccrs development

By Jonathan Corbet
October 1, 2024
Cauldron
Gemini-1.5-flash translation
https://lwn.net/Articles/991199/

Rust 语言经常被人们诟病的问题是只有一款编译器，这使得很难确定该语言的标准版本，也限制了 Rust 代码可以针对的架构只能是现有编译器所支持的架构。在 GCC 中添加 Rust 前端将有助于解决这些问题。在 2024 年 GNU 工具大熔炉（2024 GNU Tools Cauldron） 上，Pierre-Emmanuel Patry 介绍了这项工作的进展情况及其目标。

这种 GCC 前端 被称为 "gccrs"；由于 Rust 语言的商标规则限制，它不能被称为 Rust 编译器。自该项目于 2019 年重启以来，Patry 开始将目标定为 Rust 语言的 1.49 版本，该版本于 2020 年 发布。自 GCC 14 版本以来，它已包含在 GCC 中，尽管该版本没有包含 gccrs 文档。

在 2023 年的 GNU 工具大熔炉上，Patry 曾 表示 该项目在其仓库中拥有超过 800 个需要上游到 GCC 主线（mainline 的非合并变更集提交，这确实是一项相当庞大的工作。今年，这个数字已经减少到 40 个，并且这些都是新的工作，而不是来自去年的遗留工作。因此，确实取得了一些进展。曾经的目标是每两周向上游推送一次更改，但这被证明是过多的工作量了；他们仍然希望尽快将代码上游，但他们已经放弃了这个具体目标。

在过去的一年里，gccrs 的开发得到了三个 Google 暑期代码实践 (GSoC) 实习生的帮助。其中一位实习生 (Jasmine Tang) 负责内联汇编代码的支持，这是 Rust-for-Linux 项目所需要的；该功能的大部分前端工作现在已经完成。Rust 中的内联汇编代码看起来像这样：

unsafe {
    asm!("assembly code here", "other info")
};

虽然前端工作已经到位，但在将汇编代码完整地传递到后面的编译阶段时遇到了困难。这些问题已经得到解决，但仍然有一些细节需要处理。

第二位 GSoC 学生 (Muhammad Mahad) 负责开发测试套件适配器（test-suite adapter），目的是帮助 gccrs 通过 Rust 测试套件。这里存在一个需要解决的适配问题：GCC 使用 DejaGnu 进行测试，因此需要对 Rust 的测试进行某种转换。最后一位 GSoC 学生 (Kushal Pal) 负责 GCC 中间表示（intermediate representation）中的借用检查（borrow checking），以及向用户提供合适的错误提示。

展望即将到来的 GCC 15 版本，Patry 表示 主要目标 是实现编译内核代码所需的特性。其中最重要的任务是让 gccrs 能够编译 Rust 核心库，事实证明这并非易事。开发人员曾经以为他们已经实现了足够的功能来做到这一点，但惊讶地发现还有很多问题需要解决。Rust 项目使用核心库中的实验特性这一习惯也加剧了问题。

Patry 说，这些问题正在解决，但即使解决之后，编译器目前速度也相当慢。不过，这是一个需要在完成功能和正确性工作，以及核心库能够编译之后才能考虑的问题。

Patry 最后谈到了一些更长远的目标，首先是再次编译核心库，但这次不修改库本身。开发人员希望赶上目前 Rust-for-Linux 所使用的 1.78 版本。他说，这不像人们想象的那样是一个巨大的飞跃；许多 1.78 的功能在很久以前就已成为实验性功能，并且已经在 gccrs 中实现了。除此之外，他说，该项目最终将解决构建 std 库 的问题，并且有一天会努力赶上 rustc 编译器。

这次会议给人的印象是，gccrs 开发人员正在努力填补 Rust 的第二个编译器空白，但他们的人手严重不足。这是一个重要的项目，确实应该吸引一些重要的公司支持，但实际上并没有发生。除非业界有更多人站出来推动这项工作，否则 Rust 可能注定在很长一段时间内都只有一种编译器。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～