Megjelent a Rust 1.96 programozási nyelv új verziója, amelyet a Mozilla projekt indított, de ma már független, nonprofit szervezet, a Rust Foundation fejleszt. A nyelv a memória biztonságos kezelésére összpontosít, és eszközöket kínál a feladatok magas fokú párhuzamosságának eléréséhez, mindezt a szemétgyűjtő és a runtime (a runtime a alapvető inicializálásra és a standard könyvtár kíséretére korlátozódik) használata nélkül.
A Rust memória kezelésének módszerei arra irányulnak, hogy kiküszöböljék a pointerekkel végzett manipuláció során fellépő hibákat, és megvédjék a memória alacsony szintű használatából adódó problémáktól, mint például a már felszabadított memória területekhez való hozzáférés, a null pointerek dereferálása, a buffer túlfolyás és hasonlók. A könyvtárak terjesztésére, a fordítás biztosítására és a projektek függőségeinek kezelésére a Cargo csomagkezelő fejlődik.
A memória biztonságos kezelése a Rustban a fordítási időben történik, a hivatkozások ellenőrzésén, az objektumok tulajdonjogának nyomon követésén, az objektumok élettartamának (láthatóságának) figyelembevételén és a memória hozzáférésének helyességének értékelésén keresztül a kód futtatásakor. A Rust emellett eszközöket biztosít az egész számok túllépésének elleni védelemhez, kötelezővé teszi a változók értékeinek inicializálását használat előtt, jobban kezeli a hibákat a standard könyvtárban, alkalmazza a változatlan (immutable) hivatkozások és változók fogalmát alapértelmezés szerint, és erős statikus típussal minimalizálja a logikai hibákat.
Főbb újítások:
- Új range modult adtak hozzá, amely új típusok megvalósítását tartalmazza, amelyek a régi Range, RangeInclusive, RangeToInclusive és RangeFrom típusok helyébe lépnek, és lehetővé teszik a tartományok tárolását Copy-struktúrákban. A Range típus a minimális és maximális megengedett értékekkel határolt tartományokat definiál (de nem beleértve ezeket), míg a RangeFrom típus az adott értéktől kezdődően megadott számokat határoz meg, a RangeInclusive típus viszont a megadott tartomány mindkét határát tartalmazó értékeket definiál. A jövőbeli kiadásokban további RangeFull és RangeTo típusok jelennek meg, a régi megvalósítást a core::range::legacy::* alá költöztetik, a „N..M” szintaxist pedig az új típusvariánsokra alakítják.
Az új típusok abban különböznek, hogy Iterator típus helyett az IntoIterator típust valósítják meg, vagyis a beépített iterátor helyett azt definiálják, hogy hogyan alakítható át egy típus iterátorá. Ez a megközelítés lehetővé teszi az új típusokkal a másolási művelet alkalmazását (Copy típus, amely azt mutatja, hogy a típus értékei egyszerű másolással megduplázhatók), amely korábban a beépített iterátorokkal való összeegyeztethetetlenség miatt nem volt elérhető.
Például az új típusok lehetővé teszik a szelet határai egy olyan struktúrában való tárolását, amely teljesen másolható anélkül, hogy külön-külön kellene megőrizni a kezdeti és végső értékeket:use core::range::Range;
#[derive(Clone, Copy)]
pub struct Span(Range);impl Span {
pub fn of(self, s: &str) -> &str {
&s[self.0]
}
} - Új „assert_matches!” és „debug_assert_matches!” makrókat adtak hozzá, amelyek ellenőrzik, hogy az érték megfelel-e a megadott mintának, és vészhelyzet esetén leállítják a végrehajtást eltérés esetén. A „assert!(matches!(..))” és a „debug_assert!(matches!(..))” kifejezésektől eltérően az új makrók hibaértékekkel kapcsolatos hibakeresési információt adnak ki. A hasonló nevű, külső makrókkal való ütközések elkerülése érdekében az új makrók egyértelműen megkövetelik a „core::assert_matches” könyvtár importálását.
use core::assert_matches;
fn get_random_number() -> u32 {
4
}fn main() {
assert_matches!(get_random_number(), 1..=6);
} - WebAssembly célplatformra történő fordításakor leállt a linker-nek az «—allow-undefined» opció átadása, amely lehetővé tette a nem definiált szimbólumok összekapcsolását, amelyek az «env» modulból történő importálásra alakultak át. WebAssembly-re történő fordítás során mostantól minden linkerrel kapcsolatos szimbólumnak alapértelmezés szerint kötelezően definiálva kell lennie. A régi viselkedés visszaállításához használható a «RUSTFLAGS=-Clink-arg=—allow-undefined» környezeti változó vagy a ‘#[link(wasm_import_module = «env»)]’ kód kifejezés.
- Új API-k kerültak a stabil kiadások közé, beleértve a metódusok és típusimplementációk stabilizálását:
- assert_matches!
- debug_assert_matches!
- From for AssertUnwindSafe
- From for LazyCell
- From for LazyLock
- core::range::RangeToInclusive
- core::range::RangeToInclusiveIter
- core::range::RangeFrom
- core::range::RangeFromIter
- core::range::Range
- core::range::RangeIter
- A Cargo csomagkezelőben megszüntették a CVE-2026-5223 sebezhetőséget, amely használható más crate csomag forráskódjának felülírására a helyi csomagok gyorsítótárában, amikor a csomagok belső szimbolikus linkjeivel manipulálnak. A sebezhetőség csak harmadik féltől származó csomagokkal való munka közben jelentkezik, és nem érinti a crates.io tároló felhasználóit, mivel a crates.io-ban tilos szimbolikus linkekkel rendelkező csomagok feltöltése.
Továbbá megemlíthető a nyelv Rust firmware-ek mikrokontrollerekhez és korlátozott erőforrású beágyazott rendszerekhez való alkalmasságának elemzéséről szóló eredmények (PDF) közzététele.
A kutatást az STMicroelectronics végezte több európai egyetem részvételével. Két izolált fejlesztőcsapat feladata az volt, hogy ugyanazt a firmware-t valósítsák meg az Arm Cortex-M33 processzorral rendelkező STM32U585AI mikrokontrollereken. Az első csapat C nyelven készítette a firmware-t, míg a második Rust nyelven.
A kész munka tesztelése nem tárt fel lényeges előnyöket a C nyelv Rust-ra cserélésekor a mikrokontrollerek firmware-ének fejlesztése során, figyelembe véve a memóriafogyasztást és a teljesítményt. Sőt, a Rust nyelven írt rendszersziget felhasználása az Ariel OS nyílt projektből alacsonyabb memóriafogyasztást eredményezett a Rust projektben, mint a C nyelven, amely a newlib könyvtárra alapozva készült.
A Rust projekt eredményeként a firmware mérete 84100 byte volt, míg a C projekt esetében 76744 byte (10%-kal kevesebb), de a Rust firmware memóriafogyasztása jelentősen alacsonyabb volt — 24640 byte a 42608 byte helyett. A teljesítmény tekintetében, a 6 héten belül fejlesztett kezdeti prototípusok tesztelése során a Rust megvalósítás a C megvalósítást kétszeresen felülmúlta, de mindkét megvalósítás jelentősen elmaradt a becsült maximális teljesítménytől. A 4 hetes optimalizálás során mindkét megvalósítás körülbelül azonos eredményeket ért el, közel a becsült maximumhoz.
Forrás: opennet.ru
