Rust 1.96.0 जारी

• Rust 1.96.0 को rustup update stable से इंस्टॉल किया जा सकता है, और आने वाले releases के verification में beta/nightly चैनल पर भाग लिया जा सकता है
• नए core::range::Range* types Iterator की जगह IntoIterator implement करते हैं, इसलिए Copy implementation संभव है, और आगे चलकर यही range syntax के default type बनेंगे
• assert_matches! और debug_assert_matches! pattern mismatch होने पर value का Debug representation भी दिखाते हैं, जिससे test failure का diagnosis आसान होता है
• WebAssembly targets अब default रूप से --allow-undefined pass नहीं करते, इसलिए undefined symbols अब import बनने के बजाय linker error बनते हैं
• Cargo में third-party registry users के लिए CVE-2026-5223 और CVE-2026-5222 fixes शामिल हैं, जबकि crates.io users प्रभावित नहीं होते

---

Rust 1.96.0 के मुख्य बदलाव

• अपडेट और टेस्ट चैनल

  • जिन users ने मौजूदा Rust को rustup से इंस्टॉल किया है, वे rustup update stable से Rust 1.96.0 प्राप्त कर सकते हैं
  • अगर rustup नहीं है, तो Rust वेबसाइट के rustup install page से इसे इंस्टॉल किया जा सकता है, और 1.96.0 की detailed release notes भी उपलब्ध हैं
  • आने वाले releases के verification में भाग लेने के लिए rustup default beta या rustup default nightly के जरिए beta/nightly channels का उपयोग किया जा सकता है, और bugs को Rust issue tracker में report किया जा सकता है

• नए Range* types

  • मौजूदा Range और संबंधित core::ops types से कई users Copy की अपेक्षा करते हैं, लेकिन ये सीधे Iterator implement करते हैं, इसलिए इन्होंने Copy साथ में implement नहीं किया था
  • एक ही type पर Iterator और Copy दोनों implement करना Clippy के अनुसार एक footgun है, इसलिए इससे बचा जा रहा था
  • RFC3550 ने Iterator की जगह IntoIterator implement करने वाले वैकल्पिक range types का प्रस्ताव दिया, और इस संरचना में ये types Copy भी implement कर सकते हैं
  • standard library में core::range::Range, core::range::RangeFrom, core::range::RangeInclusive और उनसे जुड़े iterators stabilize किए गए हैं
  • निकट भविष्य के Rust versions में core::ops से re-export होने वाले core::range::RangeFull और core::range::RangeTo, और मौजूदा range types के नए स्थान core::range::legacy::* भी जोड़े जाएंगे
  • 0..1 जैसे range syntax अभी legacy types बनाते हैं, लेकिन भविष्य के editions में यह core::range types में बदल जाएगा
  • इस नए stabilization के बाद start और end को अलग किए बिना slice accessors को Copy type में store किया जा सकता है
  • उदाहरण:

    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 fields को public रखता है, और legacy version की तरह exhausted iterator state को expose होने से बचाने की जरूरत नहीं है
  • नए types में iteration शुरू करने से पहले conversion करना पड़ता है, इसलिए public fields कोई समस्या नहीं हैं
  • library authors को public API में legacy और नए दोनों range types स्वीकार करने के लिए impl RangeBounds उपयोग करने पर विचार करना चाहिए
  • अगर concrete type की जरूरत हो, तो भविष्य में default बनने वाले नए range types को प्राथमिकता देना सुझाया गया है

• pattern matching assertion macros

  • नए macros assert_matches! और debug_assert_matches! जांचते हैं कि value दिए गए pattern से मेल खाती है या नहीं, और मेल न खाने पर उस value के Debug representation के साथ panic करते हैं
  • ये दोनों macros मूलतः assert!(matches!(..)) और debug_assert!(matches!(..)) जैसे ही हैं, लेकिन failure पर दिखाई जाने वाली value की वजह से diagnosability बेहतर हो जाती है
  • यही नाम देने वाले लोकप्रिय third-party crates के साथ टकराव हो सकता था, इसलिए इन्हें standard prelude में नहीं जोड़ा गया
  • उपयोग से पहले इन्हें core या std से सीधे import करना होगा
  • उदाहरण:

    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 target में बदलाव

  • WebAssembly targets अब linker को --allow-undefined pass नहीं करते
  • link के समय undefined symbols अब "env" module के WebAssembly import में convert नहीं होते, बल्कि linker error बनते हैं
  • अगर link से जुड़े symbols सभी define नहीं हैं, तो module link नहीं होगा, जिससे bugs जल्दी पकड़े जा सकते हैं और symbol names जैसी चीजों से होने वाली आकस्मिक समस्याएं रोकी जा सकती हैं
  • undefined link-related symbols आमतौर पर build-time bug या configuration error को दर्शाते हैं
  • अगर पुराना behavior जानबूझकर उपयोग किया जा रहा था, तो RUSTFLAGS=-Clink-arg=--allow-undefined से उसे वापस लाया जा सकता है, या source code में symbol define करने वाले block पर #[link(wasm_import_module = "env")] इस्तेमाल किया जा सकता है
  • यह बदलाव पिछली blog announcement के बाद Rust 1.96 में लागू किया गया

stabilize किए गए API और security fixes

• stabilize किए गए API

  • 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 के लिए 2 security advisories

  • Rust 1.96 में third-party registry users के लिए Cargo की 2 vulnerabilities के fixes शामिल हैं
  • CVE-2026-5223 symbolic link वाले crate tarball extraction से जुड़ी मध्यम गंभीरता की vulnerability है
  • CVE-2026-5222 normalized URL के जरिए authentication से जुड़ी कम गंभीरता की vulnerability है
  • crates.io users इन दोनों vulnerabilities से प्रभावित नहीं होते

• अतिरिक्त बदलाव

  • Rust 1.96.0 changes
  • Cargo 1.96 changes
  • Clippy changes

[GN⁺]

Lobste.rs की राय

• assert_matches को बार-बार चाहने लगता हूँ, लेकिन हर बार यह सोचना पड़ता है कि नया crate जोड़ूँ या इसे खुद फिर से implement करूँ
  इसलिए इसका standard library में आना स्वागतयोग्य है

  • क्या यह अजीब है कि मैं tests में सैकड़ों bracket pairs हटाने की संभावना को लेकर उत्साहित हूँ? मुझे तो बिल्कुल नहीं लगता

• ranges को Copy type बनाने की दिशा मुझे पसंद आई
  कभी-कभी range को clone करना पड़ता है, यह देखकर मैं चौंका हूँ, और यह उस intuition से भी बेहतर मेल खाता है कि 12..34 छोटा और copyable data होना चाहिए
  हालाँकि, अगर एक ही नाम वाले कई types हो गए, तो थोड़ी चिंता है कि अगली बार VS Code use declaration अपने-आप जोड़ते समय कहीं गलत type न import कर दे

  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 का edition system काफ़ी अच्छा विचार लगता है

  • जहाँ तक मुझे पता है, अगर imports में ambiguity हो, तो VS Code की code action को यह चुनने के लिए dropdown खोलना चाहिए कि कौन-सा इस्तेमाल करना है
  • शायद ऐसी types को आम तौर पर बार-बार import करने की ज़रूरत नहीं होती
    ज़्यादातर users के लिए नए types का फ़ायदा छोटा है, इसलिए वे बस मौजूदा types का इस्तेमाल जारी रख सकते हैं, और अगली edition boundary पर नए types अपने-आप इस्तेमाल होने लगेंगे
    लगता है कि types को import मुख्य रूप से वे library authors करेंगे जो दोनों versions को explicitly support करना चाहते हैं

• 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.
  यह थोड़ा अजीब लगता है
  क्या इसे बाद में बदलने की योजना है? यह वैसी चीज़ लगती है जिसे ecosystem के शिफ्ट हो जाने के बाद, मान लीजिए लगभग 3 साल में, छोटी सफ़ाई के तौर पर बदला जा सकता है

  • ऐसे मामलों में edition मददगार होती है
    prelude को बदला जा सकता है बिना मौजूदा projects को तोड़े