GCC 13 中將不會引入對Rust 的支援- 科技資訊

第一個官方GCC 13 版本即將發布，但GCC 的Rust 前端項目gccrs 卻不會如期出現在此版本中。

去年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。

此外，他們還邀請更多有誌之士加入其核心團隊，或者提供一些贊助。

更多詳情可查看完整公告。

相關閱讀：