Rust 1.64 通用編程語言的發布已經發布，該語言由 Mozilla 項目創建，但現在由獨立的非營利組織 Rust 基金會贊助開發。 該語言專注於內存安全，並提供實現高作業並行性的方法，同時避免使用垃圾收集器和運行時（運行時減少為標準庫的基本初始化和維護）。
Rust 的內存處理方法使開發人員在操作指針時避免錯誤，並防止由於低級內存處理而出現的問題，例如在內存區域被釋放後訪問它、取消引用空指針、緩衝區溢出等。 為了分發庫、提供構建和管理依賴項，該項目開發了 Cargo 包管理器。 crates.io 存儲庫支持託管庫。
Rust 在編譯時通過引用檢查、跟踪對象所有權、跟踪對像生命週期（範圍）以及評估代碼執行期間內存訪問的正確性來提供內存安全。 Rust 還提供防止整數溢出的保護，要求在使用前強制初始化變量值，更好地處理標準庫中的錯誤，默認應用不可變引用和變量的概念，提供強靜態類型以最小化邏輯錯誤。
主要創新：
- 編譯器、Cargo 包管理器和標準 libstd 庫對 Linux 環境的要求均已提高 - Glibc 的最低要求已從版本 2.11 提高到 2.17，Linux 內核從版本 2.6.32 提高到 3.2。 這些限制也適用於使用 libstd 構建的 Rust 二進製文件。 發行版 RHEL 7、SLES 12-SP5、Debian 8 和 Ubuntu 14.04 滿足新要求。 將停止對 RHEL 6、SLES 11-SP4、Debian 7 和 Ubuntu 12.04 的支持。 我們鼓勵在具有較舊 Linux 內核的環境中使用 Rust 構建的可執行文件的用戶升級其係統，保留較舊的編譯器版本，或維護自己的 libstd 分支以保持兼容性。
棄用對舊版 Linux 系統的支持的原因之一是繼續保持與舊版環境的兼容性的資源有限。 對舊版 Glibcs 的支持需要使用舊版 CI 檢查、LLVM 中增加的版本控制要求以及交叉編譯實用程序。 內核版本要求的增加是由於 libstd 能夠使用新的系統調用，而無需維護層以確保與舊內核的兼容性。
- 穩定了 IntoFuture 特性，它類似於 IntoIterator，但與後者不同的是使用“.await”而不是“for … in …”循環。 與 IntoFuture 結合使用時，“.await”關鍵字不僅可以預期 Future 特徵，還可以預期可以轉換為 Future 的任何其他類型。
- rust-analyzer 實用程序包含在 Rust 版本附帶的實用程序集合中。 該實用程序還可以與 rustup 一起安裝（rustup 組件添加 rust-analyzer）。
- Cargo 包管理器實現工作區繼承，以消除典型字段值的包之間的重複，例如 Rust 版本和存儲庫 URL。 此外，還添加了對同時構建多個目標平台的支持（現在可以在“--target”選項中指定多個參數）。
- API 的新部分已移至穩定類別，包括特性的方法和實現已穩定：
- 未來::走向未來
- num::NonZero*::checked_mul
- num::NonZero*::checked_pow
- num::NonZero*::saturating_mul
- num::NonZero*::saturating_pow
- num::NonZeroI*::abs
- num::NonZeroI*::checked_abs
- num::NonZeroI*::overflowing_abs
- num::NonZeroI*::saturating_abs
- num::NonZeroI*::unsigned_abs
- num::NonZeroI*::wrapping_abs
- num::NonZeroU*::checked_add
- num::NonZeroU*::checked_next_power_of_two
- num::NonZeroU*::saturating_add
- os::unix::process::CommandExt::process_group
- os::windows::fs::FileTypeExt::is_symlink_dir
- os::windows::fs::FileTypeExt::is_symlink_file
- 之前穩定在 std::ffi 模塊中的 C 兼容類型已添加到主要組合（核心）和分配庫中：
- 核心::ffi::CStr
- 核心::ffi::FromBytesWithNulError
- 分配::ffi::CString
- 分配::ffi::FromVecWithNulError
- 分配::ffi::IntoStringError
- 分配::ffi::NulError
- 之前在 std::os::raw 模塊中穩定的 C 類型已添加到 core::ffi 和 std::ffi 模塊中（例如，已為 C 類型 uint 和 ulong 提議了 c_uint 和 c_ulong 類型） ）：
- ffi::c_char
- ffi::c_double
- ffi::c_float
- 菲::c_int
- 菲::c_long
- 菲::c_longlong
- ffi::c_schar
- ffi::c_short
- 菲::c_uchar
- ffi::c_uint
- 菲::c_ulong
- 菲::c_ulonglong
- ffi::c_ushort
- 低級處理程序已穩定用於 Poll 機制（將來計劃提供不需要使用低級 Pull 和 Pin 結構的簡化 API）：
- 未來::poll_fn
- 任務::準備好了！
- “const”屬性決定了在任何上下文中使用它而不是常量的可能性，在 slice::from_raw_parts 函數中使用。
- 為了更緊湊地存儲數據，Ipv4Addr、Ipv6Addr、SocketAddrV4 和 SocketAddrV6 結構體的內存佈局已更改。 可能會破壞與使用 std::mem::transmute 進行低級結構操作的單個 crate 包的兼容性。
- Windows平台的rust編譯器的彙編使用了PGO優化（profile-guided optimization），這使得代碼編譯性能提高了10-20%。
- 編譯器對某些結構中未使用的字段實施了新的警告。
此外，我們還可以注意到有關 Rust 語言編譯器替代實現開發的狀態報告，該報告由 gccrs 項目 (GCC Rust) 編寫並批准包含在 GCC 中。 集成前端后，可以使用標準GCC工具包來編譯Rust程序，無需安裝使用LLVM開發構建的rustc編譯器。 只要開發按計劃進行，並且排除任何不可預見的問題，Rust 語言前端將集成到計劃於明年 13 月發布的 GCC 13 中。 GCC XNUMX 中的 Rust 實現將處於 beta 狀態，默認情況下尚未啟用。
來源： opennet.ru