Rust 1.96.0 diumumkan

• Rust 1.96.0 dapat diinstal dengan rustup update stable, dan verifikasi rilis mendatang bisa diikuti melalui kanal beta/nightly
• Tipe baru core::range::Range* mengimplementasikan IntoIterator alih-alih Iterator, sehingga bisa mengimplementasikan Copy dan ke depannya akan menjadi tipe bawaan untuk sintaks rentang
• assert_matches! dan debug_assert_matches! menampilkan representasi Debug dari nilai saat pola tidak cocok, sehingga diagnosis kegagalan pengujian menjadi lebih mudah
• Target WebAssembly tidak lagi meneruskan --allow-undefined secara default, sehingga simbol yang tidak terdefinisi menjadi error linker, bukan import
• Cargo mencakup perbaikan untuk CVE-2026-5223 dan CVE-2026-5222 bagi pengguna registry pihak ketiga, dan pengguna crates.io tidak terdampak

---

Perubahan utama di Rust 1.96.0

• Pembaruan dan kanal pengujian

  • Pengguna yang memasang Rust yang ada melalui rustup bisa mendapatkan Rust 1.96.0 dengan rustup update stable
  • Jika belum memiliki rustup, Anda dapat menginstalnya dari halaman instalasi rustup di situs Rust, dan catatan rilis terperinci 1.96.0 juga telah dipublikasikan
  • Untuk berpartisipasi dalam verifikasi rilis mendatang, Anda dapat menggunakan kanal beta/nightly dengan rustup default beta atau rustup default nightly, dan bug dapat dilaporkan ke pelacak isu Rust

• Tipe Range* baru

  • Range lama dan tipe terkait di core::ops selama ini diharapkan banyak pengguna sebagai Copy, tetapi tidak mengimplementasikannya karena secara langsung mengimplementasikan Iterator
  • Mengimplementasikan Iterator dan Copy pada tipe yang sama adalah footgun yang disorot oleh Clippy, sehingga sebelumnya dihindari
  • RFC3550 mengusulkan tipe rentang alternatif yang mengimplementasikan IntoIterator alih-alih Iterator, dan dengan struktur ini tipe-tipe tersebut juga dapat mengimplementasikan Copy
  • Di pustaka standar, core::range::Range, core::range::RangeFrom, core::range::RangeInclusive beserta iterator terkait kini telah distabilkan
  • Dalam versi Rust yang akan datang, core::range::RangeFull dan core::range::RangeTo yang diekspor ulang dari core::ops, serta core::range::legacy::* yang akan menjadi lokasi baru bagi tipe rentang saat ini, juga akan ditambahkan
  • Sintaks rentang seperti 0..1 saat ini masih membuat tipe legacy, tetapi dalam edisi mendatang akan berubah menjadi tipe core::range
  • Dengan stabilisasi baru ini, aksesori slice kini dapat disimpan dalam tipe Copy tanpa harus memisahkan start dan end
  • Contoh:

    use core::range::Range;
    
    #[derive(Clone, Copy)]
    pub struct Span(Range<usize>);
    
    impl Span {
        pub fn of(self, s: &str) -> &str {
            &s[self.0]
        }
    }
    

  • RangeInclusive baru membuka field-nya, karena tidak perlu menghindari paparan status iterator yang sudah habis seperti pada versi legacy
  • Tipe baru ini harus dikonversi terlebih dahulu sebelum iterasi dimulai, sehingga field publik bukan menjadi masalah
  • Penulis library sebaiknya mempertimbangkan penggunaan impl RangeBounds pada API publik agar dapat menerima baik tipe rentang legacy maupun tipe baru
  • Jika membutuhkan tipe konkret, disarankan untuk memilih tipe rentang baru yang nantinya akan menjadi default

• Makro asersi pencocokan pola

  • Makro baru assert_matches! dan debug_assert_matches! memeriksa apakah sebuah nilai cocok dengan pola yang diberikan, dan jika tidak cocok akan panic sambil menampilkan representasi Debug dari nilai tersebut
  • Kedua makro ini pada dasarnya setara dengan assert!(matches!(..)) dan debug_assert!(matches!(..)), tetapi kemudahan diagnosis meningkat berkat nilai yang ditampilkan saat gagal
  • Karena bisa berbenturan dengan crate pihak ketiga populer yang menyediakan makro dengan nama sama, keduanya tidak ditambahkan ke prelude standar
  • Sebelum digunakan, makro harus diimpor langsung dari core atau std
  • Contoh:

    use core::assert_matches;
    
    /// [Random Number](https://xkcd.com/221/)
    fn get_random_number() -> u32 {
        // chosen by a fair dice roll.
        // guaranteed to be random.
        4
    }
    
    fn main() {
        assert_matches!(get_random_number(), 1..=6);
    }
    

• Perubahan pada target WebAssembly

  • Target WebAssembly tidak lagi meneruskan --allow-undefined ke linker
  • Saat proses linking, simbol yang tidak terdefinisi tidak lagi dikonversi menjadi import WebAssembly dari modul "env", melainkan menjadi error linker
  • Jika semua simbol terkait linking harus terdefinisi agar modul dapat ditautkan, bug bisa ditemukan lebih awal dan masalah tak disengaja seperti pada nama simbol dapat dicegah
  • Simbol terkait linking yang tidak terdefinisi biasanya menunjukkan bug saat build atau kesalahan konfigurasi
  • Jika perilaku lama memang diinginkan, Anda dapat mengembalikannya dengan RUSTFLAGS=-Clink-arg=--allow-undefined, atau menggunakan #[link(wasm_import_module = "env")] pada blok yang mendefinisikan simbol di kode sumber
  • Perubahan ini diterapkan di Rust 1.96 setelah pengumuman blog sebelumnya

API yang distabilkan dan perbaikan keamanan

• API yang distabilkan

  • assert_matches!
  • debug_assert_matches!
  • From<T> for AssertUnwindSafe<T>
  • From<T> for LazyCell<T, F>
  • From<T> for LazyLock<T, F>
  • core::range::RangeToInclusive
  • core::range::RangeToInclusiveIter
  • core::range::RangeFrom
  • core::range::RangeFromIter
  • core::range::Range
  • core::range::RangeIter

• Dua advisori keamanan Cargo

  • Rust 1.96 mencakup perbaikan untuk dua kerentanan Cargo bagi pengguna registry pihak ketiga
  • CVE-2026-5223 adalah kerentanan tingkat sedang yang terkait dengan ekstraksi tarball crate yang memiliki symbolic link
  • CVE-2026-5222 adalah kerentanan tingkat rendah yang terkait dengan autentikasi melalui URL yang dinormalisasi
  • Pengguna crates.io tidak terdampak oleh kedua kerentanan tersebut

• Perubahan tambahan

  • Perubahan Rust 1.96.0
  • Perubahan Cargo 1.96
  • Perubahan Clippy

[GN⁺]

Pendapat di Lobste.rs

• Saya terus merasa ingin punya assert_matches, tetapi setiap kali itu terjadi saya jadi bimbang apakah harus menambahkan crate baru atau mengimplementasikannya ulang sendiri
  Jadi, menyenangkan melihatnya masuk ke standard library

  • Apakah aneh kalau saya antusias karena bisa menghapus ratusan pasang tanda kurung di pengujian? Menurut saya tidak sama sekali

• Saya suka langkah untuk membuat range menjadi tipe Copy
  Kadang saya terkejut saat harus mengkloning range, dan ini juga lebih sesuai dengan intuisi bahwa 12..34 seharusnya berupa data kecil yang bisa disalin
  Namun, kalau ada beberapa tipe dengan nama yang sama, saya agak khawatir VS Code akan mengambil tipe yang salah saat berikutnya otomatis menambahkan deklarasi use

  A Rust version in the near future will also add [...] core::range::legacy::* as the new home for the current ranges. Range syntax like 0..1 still produces the legacy types for now, but will be updated to core::range types in a future edition.
  Sistem edition Rust tampak seperti ide yang cukup bagus

  • Setahu saya, jika muncul ambiguitas dalam import, code action di VS Code seharusnya membuka dropdown untuk memilih yang mana yang akan dipakai
  • Rasanya tidak perlu terlalu sering mengimpor tipe seperti ini dalam penggunaan sehari-hari
    Bagi kebanyakan pengguna, manfaat tipe baru ini kecil, jadi cukup terus pakai tipe lama saja, lalu di batas edition berikutnya tipe baru akan mulai dipakai secara otomatis
    Sepertinya yang terutama akan mengimpor tipe ini adalah penulis library yang ingin secara eksplisit mendukung kedua versi

• These new macros have not been added to the standard prelude, because they would collide with popular third-party crates that provide macros with the same name. Instead, they should be manually imported from core or std before use.
  Ini terasa agak aneh
  Apakah ada rencana untuk mengubahnya nanti? Ini terlihat seperti jenis hal yang mungkin ingin dibenahi secara kecil-kecilan setelah ekosistem beralih, misalnya sekitar 3 tahun lagi

  • Edition membantu untuk hal seperti ini
    Prelude bisa diubah tanpa merusak proyek yang sudah ada