去年 12 月，Gccrs 被批准合并到 GCC 主线，所有 gccrs 代码也都被合并到了 GCC 13 上游代码库中。但时至今日，编译器仍未就支持 Rust 做好准备。开发人员 Philip Herron 和 Arthur Cohen 发文解释称：

我们的期望是，通过明确表示编译器仍未为真正的 Rust 代码做好准备；可以从早期用户那里得到有价值的反馈，以及来自两个不同社区（Rust 社区和 GCC 社区）的更多参与。我们计划在最后的发布期限之前尽可能的完成更多工作，但现在 GCC 13.1 版本已经来临，我们在完整性方面仍然没有达到目标。

这意味着当使用 gccrs 时，你仍然无法实现如 “Hello World!” 之类的 “easy Rust things”，也不能使用常用的标准库。同样，对于 Rust 编程语言必不可少的更复杂的概念（如 borrow-checking）也尚未实现；如果没有这些功能， gccrs 将不会被认为是完整的。我们认为这会给不知情的用户带来很多困惑，他们可能会将 gccrs 视为官方 GCC 版本的一部分，并期望得到一个可用的编译器。

公告指出，gccrs 未在 GCC 13 中准备好，跟 Rust 本身 “nothing will work, unless everything works” 的严格设计脱不了干系。Rust 标准库可以被看作是几个相互依赖的 crates，其中两个主要组成部分是 core 和 alloc。就目前而言，gccrs 还不能编译其目标版本的 core crate；虽然 Philip 正在推进该方面的工作，但这一落后还是 “严重影响了我们的类型系统和编译器中的第二个中间表示”。

另一方面，尽管开发人员旨在以 Rust 1.49 版本的核心库为目标，但也需要实现那些在 Rust 的后期版本中才稳定下来 (或者说至今仍可能是不稳定的) 的功能。为此，开发人员需要进行大量的调查工作。其举例称，用户可能希望 gccrs 处理这样一个代码片段：

fn main() {
    println!("Hello, world!");
}

但 gccrs 目前根本不能实现。“如果你对 Rust 有一点了解，你就会知道 println! 是一个宏调用。宏是很复杂的，但也是非常强大的。我们已经对它们进行了一段时间的研究，一些更复杂的功能仍未正确实现...... 虽然所有这些看起来都很容易理解和使用，但 Rust 编译器必须做很多工作来处理这些宏调用！”

值得一提的是，开发团队最近也开始了 Rust 过程宏 (Procedural Macros) 的相关工作，由 Pierre-Emmanuel Patry 领导。

Philip 和 Arthur 在公告中表示，虽然没能赶上 GCC 13 的发布，但他们依然对 gccrs 未来的进展充满信心。该团队计划在未来几个月里专注于 core crate 以及 borrow-checker 的实现，并开发一些必要的工具来尝试并通过 Rust 1.49 testsuite。

其目标是在下一个主要的 GCC 版本 (即 GCC 14) 中，将 Rust 1.49 版本的标准库与编译器一起发布，并希望向后移植足够多的更改到 GCC 13 分支，以便在 GCC 13.2 发布时使 core crate 能正常运行。这将使用户能够轻松地开始为 #![no_std] Rust 程序和一些嵌入式目标尝试编译器。

我们已经花费了大量时间完成与 GCC 上游的初步合并，这是一项不需要重复的工作。使得我们能够更加专注于 GCC 14 的编译器开发，并使我们能够轻松地将补丁推送到上游。这段时间将用于生产更高质量的编译器，并有望接近一个真正的 Rust 编译器。这也提高了项目的知名度，有许多文章都是关于我们对上游的各种推动。

我们将继续努力为 GCC 制作一个高质量的 Rust 编译器前端，并将坚持我们现有的原则：我们要尊重 Rust 编程语言，不以任何 way、shape 或 form 伤害它。gccrs 的目标不是要规避围绕 Rust 语言的各种程序，也不是为那些应该是无效的 Rust 代码提供一个 escape hatch。我们以 rustc 为指导，并将继续把这两个编译器之间的每一个差异视为 bug。

此外，他们还邀请更多有志之士加入其核心团队，或者提供一些赞助。

原文来自：

本文地址：//q13zd.cn/gcc-rust-gccrs.html编辑：xiangping wu，审核员：清蒸github

Linux大全：

Linux系统大全：

红帽认证RHCE考试心得：