Rust 1.81 通用編程語言的發布已經發布，該語言由 Mozilla 項目創建，但現在由獨立的非營利組織 Rust 基金會贊助開發。 該語言專注於內存安全，並提供實現高作業並行性的方法，同時避免使用垃圾收集器和運行時（運行時減少為標準庫的基本初始化和維護）。
Rust 的內存處理方法使開發人員在操作指針時避免錯誤，並防止由於低級內存處理而出現的問題，例如在內存區域被釋放後訪問它、取消引用空指針、緩衝區溢出等。 為了分發庫、提供構建和管理依賴項，該項目開發了 Cargo 包管理器。 crates.io 存儲庫支持託管庫。
Rust 在編譯時通過引用檢查、跟踪對象所有權、跟踪對像生命週期（範圍）以及評估代碼執行期間內存訪問的正確性來提供內存安全。 Rust 還提供防止整數溢出的保護，要求在使用前強制初始化變量值，更好地處理標準庫中的錯誤，默認應用不可變引用和變量的概念，提供強靜態類型以最小化邏輯錯誤。
主要創新：
- 定義顯示的錯誤描述的 core::error::Error 特徵已經穩定。此變更可讓您使用「#![no_std]」屬性在各種庫中使用單一錯誤特徵，無論環境如何，包括在未綁定到標準庫的庫中。
- 標準庫中的穩定和不穩定排序函數已轉換為使用新演算法，從而表現出更高的效能和更低的編譯時間。在新排序演算法的實作中，可以偵測到錯誤定義的 Ord 類型，並在這種情況下輸出錯誤（恐慌），而不是隨機分組的資料。
- Linter 實作了新的檢查等級「expect」（「#[expect(lint)]」），它允許您驗證檢查是否已完成，如果檢查未完成（由於實作中的錯誤）則顯示警告或停用檢查） 。例如，當遷移程式碼庫以使用 Clippy 的 undocumented_unsafe_blocks 檢查時，您可以指定「#[expect(clippy::undocumented_unsafe_blocks)]」以確保在轉換期間記錄所有不安全區塊。 Clippy 也實作了clippy::allow_attributes 和clippy::allow_attributes_without_reason 檢查，可以輕鬆地將「#[allow]」屬性替換為「#[expect(lint)]」。
- 提供了記錄更改檢查等級 (lint) 的原因的功能，為新開發人員提供有關添加特定檢查的原因的信息，輸出為編譯器訊息。例如：#![deny(clippy::float_arithmetic, Reason =“沒有硬體浮點支援”)]
- API 的新部分已移至穩定類別，包括特性的方法和實現已穩定：
- 核心::錯誤
- 提示::assert_unchecked
- fs::存在
- AtomicBool::fetch_not
- 持續時間::abs_diff
- IoSlice::高級
- IoSlice::advance_slices
- IoSliceMut::高級
- IoSliceMut::advance_slices
- 恐慌鉤子訊息
- 恐慌訊息::消息
- 緊急訊息
“const”屬性決定了在任何上下文中使用它而不是常量的可能性，用於函數中：
- char::from_u32_unchecked（函數）
- char::from_u32_unchecked （方法）
- CStr::count_bytes
- CStr::from_ptr
類型 std::panic::PanicInfo 已重新命名為 std::panic::PanicHookInfo （保留舊名稱的功能，但從下一個版本開始，使用它會導致警告）。在這種情況下， core::panic::PanicInfo 將保持原樣，但將作為單獨的類型開發。分離類型將允許您在其中實作特定於 snd 和 no_std 上下文中執行的不同方法。
- 到 C-unwind ABI ('extern "C-unwind"') 的轉換已經完成，這與沒有 "-unwind" 後綴 ('extern "C"') 的 ABI 不同，如果展開過程保持安全行為），當程序崩潰或拋出C++ 樣式的異常時觸發，跨越ABI 邊界（例如，當透過接觸與另一種程式語言的程式碼關聯的堆疊來展開一種程式語言的程式碼中拋出的例外狀況時）。自 Rust 1.81 發布以來，「extern「C」」ABI 已啟用，可以在未偵測到的展開時崩潰。
- 已針對平台 i686-unknown-redox、xtensa-esp32-none-elf、xtensa-esp32s2-none-elf、xtensa-esp32s3-none-elf、xtensa-esp32-espidf、xtensa-esp32s2 實現第三級支援xtensa-esp32s3-espidf。第三級涉及基本支持，但沒有自動化測試、發布官方建置或檢查程式碼是否可以建置。
- 已經實現了對目標平台loongarch64-unknown-linux-musl和arm64ec-pc-windows-msvc的第二級支援。第二級支援涉及組裝保證。
- 為 Linux-LoongArch 平台上的系統配備了完整的工具包和分析器。
- std::process::Command 中僅影響平台的漏洞 (CVE-2024-43402) 已修正。 Windows 並且消除了先前修復的 BatBadBut 漏洞的變通方法。此漏洞涉及在使用 Command::arg 和 Command::args 呼叫時處理特殊字元。 Command::arg 和 Command::args 呼叫旨在直接將參數傳遞給進程，而無需命令解釋器對其進行處理。實際上，執行 bat 和 cmd 腳本時，會啟動 cmd.exe 進程，該進程有自己的參數分離邏輯。此繞過方法基於以下事實： Windows 刪除路徑中的前導空格和句點，例如，副檔名為「.bat.」的檔案將被處理為「.bat」。
值得注意的是，Wedson Almeida Filho 已卸任 Rust 專案維護者一職。 Linux參與內核實現 Linux Rust 語言的開發工具。 Wadson 離開後，該專案仍有兩位維護者：Miguel Ojeda，Rust-for-Linux還有 Python 軟體基金會前主管 Alex Gaynor，他已將重心轉移到 Rust 的推廣上。即將離任的維護者 Almeida 四年前加入該項目，他是微軟員工，也是用 Rust 編寫的 EXT2 檔案系統實驗性驅動程式的作者。 Almeida 最近的工作重點是建立用於在 Rust 中開發檔案系統的工具。今年，Almeida 為 Rust-for- 程式碼庫做出了貢獻。Linux 17 次提交（相比之下，Miguel Ojeda 提交了 53 次）。
離職的原因是缺乏曾經用來回應某些非技術性瑣事的精力和熱情。據阿爾梅達稱，開發者被迫耗費大量精力爭論一些無關緊要的問題，而這些問題卻損害了更重要的整體目標。阿爾梅達仍然堅信核心的未來在於使用記憶體安全的語言，如果開發者社群能夠… Linux 那時他們就不會理解這一點了。 Linux 將會被其他核心取代，就像當年 Unix 核心被取代一樣。
Rust-for-計畫的支持者Linux 他面臨著克服來自經驗豐富的核心開發人員的阻力，這些人認為沒有必要學習新語言。在辭職信中，阿爾梅達舉例說明了他在與肯特·奧弗斯特里特的一次演講期間發生的討論。Linux 儲存、檔案系統、記憶體管理和 BPF 高峰會”，致力於使用 Rust 進行檔案系統開發。ext2/ext3/ext4 檔案系統的作者 Ted Ts'o 對 Rust 的實現工作提出了批評，他將 Rust 實現的檔案系統與 ext2/ext3/ext4 檔案系統進行了比較。Linux 試圖強迫所有人接受Rust宗教。
針對Almeida 打算創建一個用C 編寫的檔案系統介麵包裝器以在Rust 程式碼中使用的意圖，Ted Tso 指出，這樣的包裝器將不可避免地導致問題，因為對C 介面和重構的任何更改都需要更改Rust 和他不想承擔不必要的責任來修復 Rust 程式碼中的問題和監視 Rust 綁定的狀態。 C 程式碼不斷發展，如果它的變更破壞了 Rust 框架的功能，就會導致與該框架相關的所有檔案系統中斷。
Ted 也認為，在可預見的未來，Rust 的綁定將保持次要地位，綁定問題只會給 Rust 開發者帶來麻煩。Linux而且，這並非針對核心檔案系統開發社群。有人指出，並非所有開發者都打算學習 Rust，因此，在對程式碼進行影響其他程式碼的變更後，他們只能更新依賴的 C 程式碼，而無法修復 Rust 綁定，因為他們不懂 Rust。 SCSI 子系統維護者 James Bottomley 也參與了討論，他表示，綁定中編碼的語意越多，其同步性就越脆弱。
與此同時，Google去年重寫了 pvmfm 韌體。 虛擬機已在平台上推出 Android她分享了自己逐步將 Rust 程式碼整合到最初以 C 或 C++ 編寫的現有韌體中的經驗。她示範如何透過建立功能相同的 Rust 替換組件來顯著提高韌體安全性。在實作 Rust 時，她建議專注於使用 Rust 編寫新程式碼以及執行安全關鍵功能的程式碼（例如，處理來自不可信來源的外部資料的程式碼）。為了整合 Rust 和 C 程式碼，她建議使用 shim 來轉換 Rust 和 C API 之間的呼叫（C API 匯出供 Rust 程式碼使用，反之亦然），從而允許逐步用 Rust 重寫 API 元素。
來源： opennet.ru
