Rust 1.96.0 duyuruldu

• Rust 1.96.0 rustup update stable ile kurulabilir; gelecekteki sürüm doğrulamalarına beta/nightly kanallarında katılmak mümkündür
• Yeni core::range::Range* türleri, Iterator yerine IntoIterator uygular; bu sayede Copy uygulanabilir ve gelecekte aralık sözdiziminin varsayılan türleri olmaları planlanır
• assert_matches! ve debug_assert_matches!, desen eşleşmediğinde değerin Debug gösterimini de yazdırarak test hatalarının teşhisini kolaylaştırır
• WebAssembly hedefleri artık varsayılan olarak --allow-undefined geçmediği için tanımsız semboller import yerine bağlayıcı hatasına dönüşür
• Cargo, üçüncü taraf registry kullanıcıları için CVE-2026-5223 ve CVE-2026-5222 düzeltmelerini içerir; crates.io kullanıcıları etkilenmez

---

Rust 1.96.0'daki başlıca değişiklikler

• Güncelleme ve test kanalları

  • Rust'ı rustup ile kurmuş mevcut kullanıcılar, rustup update stable ile Rust 1.96.0 sürümünü alabilir
  • rustup yoksa Rust web sitesindeki rustup kurulum sayfasından kurulabilir; ayrıca 1.96.0 ayrıntılı sürüm notları da yayımlandı
  • Gelecekteki sürüm doğrulamalarına katılmak için rustup default beta veya rustup default nightly ile beta/nightly kanalları kullanılabilir; hatalar da Rust issue tracker üzerinden bildirilebilir

• Yeni Range* türleri

  • Mevcut Range ve ilişkili core::ops türlerinde birçok kullanıcı Copy beklese de, bu türler doğrudan Iterator uyguladıkları için Copy ile birlikte uygulanmamıştı
  • Aynı türde hem Iterator hem de Copy uygulamak, Clippy'nin footgun olarak işaret ettiği bir yaklaşım olduğu için bundan kaçınılıyordu
  • RFC3550, Iterator yerine IntoIterator uygulayan alternatif aralık türleri önerdi; bu yapıda ilgili türler Copy de uygulayabilir
  • Standart kütüphanede core::range::Range, core::range::RangeFrom, core::range::RangeInclusive ve ilişkili iterator'lar stabilize edildi
  • Yakın gelecekteki Rust sürümlerine, core::ops içinden yeniden dışa aktarılan core::range::RangeFull ve core::range::RangeTo ile mevcut aralık türlerinin yeni konumu olacak core::range::legacy::* de eklenecek
  • 0..1 gibi aralık sözdizimi şu anda legacy türler üretse de, gelecekteki bir edition'da core::range türlerine geçecek
  • Bu yeni stabilizasyon sayesinde start ve end ayırmadan slice erişicileri Copy türlerinde saklamak mümkün hale geliyor
  • Örnek:

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

  • Yeni RangeInclusive, alanlarını herkese açık yapar; çünkü legacy sürümde olduğu gibi tüketilmiş iterator durumunu dışa vurma riskinden kaçınmak gerekmez
  • Yeni türlerde iterasyona başlamak için önce dönüşüm gerektiğinden, açık alanlar sorun oluşturmaz
  • Kütüphane yazarları, herkese açık API'lerde hem legacy hem de yeni aralık türlerini kabul eden impl RangeBounds kullanımını değerlendirmelidir
  • Somut bir tür gerekiyorsa, gelecekte varsayılan olacak yeni aralık türlerini tercih etmek önerilir

• Desen eşleme assertion makroları

  • Yeni assert_matches! ve debug_assert_matches! makroları, bir değerin verilen desenle eşleşip eşleşmediğini denetler; eşleşmezse değerin Debug gösterimiyle birlikte panic üretir
  • Bu iki makro özünde assert!(matches!(..)) ve debug_assert!(matches!(..)) ile aynıdır; ancak hata durumunda yazdırılan değer sayesinde teşhis edilebilirlik artar
  • Aynı adı sağlayan popüler üçüncü taraf crate'lerle çakışma yaratabileceği için standart prelude'a eklenmedi
  • Kullanmadan önce doğrudan core veya std içinden içe aktarılmaları gerekir
  • Örnek:

    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);
    }
    

• WebAssembly hedeflerindeki değişiklik

  • WebAssembly hedefleri artık bağlayıcıya --allow-undefined geçmiyor
  • Bağlama sırasında oluşan tanımsız semboller, "env" modülünün WebAssembly import'una dönüştürülmek yerine bağlayıcı hatası oluşturuyor
  • Bağlamayla ilgili tüm semboller tanımlı değilse modül hiç bağlanmayacağından, bu değişiklik hataları daha erken yakalamayı ve sembol adları gibi konulardaki kazara sorunları önlemeyi sağlıyor
  • Tanımsız bağlama sembolleri genellikle derleme zamanı hatası veya yapılandırma yanlışlığına işaret eder
  • Eski davranış kasıtlıysa RUSTFLAGS=-Clink-arg=--allow-undefined ile geri dönülebilir ya da kaynak kodda sembolü tanımlayan blokta #[link(wasm_import_module = "env")] kullanılabilir
  • Bu değişiklik, önceki blog duyurusunun ardından Rust 1.96 ile devreye alındı

Stabilize edilen API'ler ve güvenlik düzeltmeleri

• Stabilize edilen API'ler

  • 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

• Cargo için 2 güvenlik tavsiyesi

  • Rust 1.96, üçüncü taraf registry kullanıcıları için iki Cargo açığına yönelik düzeltmeler içerir
  • CVE-2026-5223, sembolik bağlantı içeren crate tarball'larının çıkarılmasıyla ilgili orta şiddette bir güvenlik açığıdır
  • CVE-2026-5222, normalize edilmiş URL üzerinden kimlik doğrulamayla ilgili düşük şiddette bir güvenlik açığıdır
  • crates.io kullanıcıları bu iki açıktan da etkilenmez

• Ek değişiklikler

  • Rust 1.96.0 değişiklikleri
  • Cargo 1.96 değişiklikleri
  • Clippy değişiklikleri

[GN⁺]

Lobste.rs yorumları

• assert_matchesi hep istemeye devam ediyorum ama her seferinde yeni bir crate ekleyip eklememek ya da kendim yeniden yazıp yazmamak arasında kalıyorum
  Bu yüzden standart kütüphaneye girmesi sevindirici.

  • Testlerde yüzlerce parantez çiftini silebilecek olmak için heyecanlanmak garip mi? Bence hiç değil.

• Aralıkların Copy tipi haline getirilmesine yönelik adımı beğendim
  Bazen bir aralığı klonlamam gerektiğine şaşırmıştım; ayrıca 12..34 ifadesinin küçük ve kopyalanabilir bir veri olması gerektiği yönündeki sezgiyle de daha uyumlu.
  Yine de aynı ada sahip birden fazla tip olursa, VS Code bir dahaki sefere use bildirimini otomatik eklediğinde yanlış tipi içe aktarır mı diye biraz endişeleniyorum.

  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.
  Rust'ın edition sistemi oldukça iyi bir fikir gibi görünüyor.

  • Bildiğim kadarıyla içe aktarmalarda belirsizlik olursa VS Code'un kod aksiyonu hangisinin kullanılacağını seçmek için bir açılır menü göstermeli.
  • Aslında bu tür tipleri normalde sık sık içe aktarmaya gerek olmaz diye düşünüyorum
    Çoğu kullanıcı için yeni tiplerin faydası küçük; bu yüzden mevcut tipleri kullanmaya devam edebilirler ve bir sonraki edition sınırında yeni tipler otomatik olarak kullanılmaya başlanır.
    Muhtemelen tipleri özellikle içe aktaracak olanlar, her iki sürümü de açıkça desteklemek isteyen kütüphane yazarları olacaktır.

• 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.
  Bu biraz tuhaf hissettiriyor.
  Bunu ileride değiştirmeyi planlıyorlar mı acaba? Ekosistem geçiş yaptıktan sonra, mesela 3 yıl kadar sonra, küçük bir temizlik kapsamında değiştirilecek türden bir şeye benziyor.

  • Editionlar bu tür durumlarda yardımcı oluyor
    Mevcut projeleri bozmadan prelude'u değiştirebilirsiniz.