Rust komanda 9. jūlijā publicēja versiju 1.97.0. Redzamākā izmaiņa nav jauna sintakse, bet kompilatora noklusējums: rustc tagad simbolu nosaukumus binārā kodē pēc v0 shēmas. Līdz šim noklusējums bija vecā, uz C++ Itanium ABI balstītā kodēšana, ko Rust aizguva vēsturiski.
Tas skar ikvienu, kas lasa kaudzes izsekojumus, profilē kodu vai atkļūdo ar gdb un perf. Vecā shēma ģenēriskos tipa parametrus slēpa aiz jaucējkoda, tāpēc simbolā nevarēja redzēt, ar ko funkcija patiešām izsaukta. v0 saglabā pašus tipus.
Ko maina v0 kodēšana
Simbolu kodēšana (symbol mangling) ir process, kā kompilators funkciju un tipu nosaukumus pārvērš unikālās virknēs, ko saprot linkeris. Rustam tas ir sarežģītāk nekā C, jo viena ģenēriska funkcija ģenerē vairākas kopijas — pa vienai katram konkrētam tipam.
Vecajā shēmā tipa argumenti tika sagriezti un aizstāti ar jaucējkodu. Divas Vec<u32> un Vec<String> instances varēja binārā izskatīties gandrīz vienādi, un atkļūdotājs rādīja tikai neko neizsakošu ciparu virkni. v0 kodē tipus tieši, tāpēc kaudzes izsekojumā ir redzams pilns tipa ceļš.
Praktiskā ietekme ir vienkārša: perf, valgrind un gdb izvade kļūst lasāmāka bez papildu rīkiem. Ja tavā CI vai monitoringā ir skripti, kas parsē simbolu nosaukumus vecajā formātā, tie jāpārbauda — formāts ir cits. Vecā shēma nav pazudusi; to var atgriezt ar karogu -C symbol-mangling-version=legacy, bet Rust komanda to uzskata par pārejas risinājumu.
Linkera ziņas vairs netiek noklusētas
Otra izmaiņa, kas ietekmē ikdienas darbu: rustc vairs klusi neizmet linkera izvadi, kad linkošana ir veiksmīga. Agrāk brīdinājumi no sistēmas linkera pazuda, ja galarezultāts bija veiksmīgs binārs, un izstrādātājs par tiem neuzzināja.
Tagad tie parādās kā jauns brīdinājums linker_messages. Shēma filtrē biežākos viltus pozitīvos, lai izvade nepārplūst. Ja projekts ģenerē zināmus, nekaitīgus linkera brīdinājumus, tos var apklusināt caur Cargo.toml:
[lints.rust]
linker_messages = "allow"Simbolu kodēšana un linkera izvade ir tā Rust daļa, ko lielākā daļa izstrādātāju nekad neredz — līdz brīdim, kad jāatkļūdo produkcijas kritums. Tieši tur šī versija atmaksājas.
Cargo brīdinājumu vadība
Cargo šajā versijā stabilizēja iestatījumu build.warnings un tam atbilstošo vides mainīgo CARGO_BUILD_WARNINGS. Tas kontrolē, kā tiek apstrādāti lint brīdinājumi no lokālajām pakotnēm, ar trim vērtībām: allow apklusina, warn rāda bez kļūdas (noklusējums), deny pārtrauc būvēšanu ar kļūdu.
Vērtība deny ir domāta CI konveijeriem, kur jebkurš brīdinājums nozīmē neveiksmi. Priekšrocība salīdzinājumā ar veco pieeju (RUSTFLAGS="-D warnings") ir tā, ka mainīgais neietekmē būvēšanas kešatmiņu — pārslēdzot to, atkārtota kompilācija nav vajadzīga. Kopā ar karogu --keep-going tas ļauj vienā piegājienā savākt kļūdas no vairākām pakotnēm.
Cargo arī stabilizēja resolver.lockfile-path, kas ļauj norādīt konkrētu ceļu līdz lock failam atkarību risināšanas laikā. Tas noder monorepo un būvēšanas vidēs, kur Cargo.lock neatrodas standarta vietā. Pilns saraksts ir releases.rs izmaiņu žurnālā.
Jaunās standarta bibliotēkas metodes
Versija stabilizēja vairākas bitu manipulācijas metodes veseliem skaitļiem. isolate_highest_one un isolate_lowest_one atgriež skaitli, kur palicis tikai augstākais vai zemākais iestatītais bits; highest_one un lowest_one dara līdzīgi, un bit_width atgriež skaitļa bitu platumu. Visas darbojas arī ar NonZero variantiem.
Šīs metodes līdz šim programmētāji rakstīja pašrocīgi ar bitu nobīdēm un leading_zeros. Tagad tās ir standartā, ar skaidriem nosaukumiem un bez kļūdu iespējas robežgadījumos.
Papildus stabilizēti: Default tipam RepeatN, Copy tipam ffi::FromBytesUntilNulError, Send tipam std::fs::File uz UEFI platformas un char::is_control const kontekstā, kas ļauj to izmantot kompilācijas laikā.
Vai vērts atjaunināt
1.97.0 nemaina esošo kodu — v0 shēma ietekmē tikai bināra iekšpusi, ne API. Riska nav, un lielākā daļa projektu var atjaunināt ar rustup update bez izmaiņām kodā. Vienīgais, ko pārbaudīt: rīki, kas paļaujas uz veco simbolu formātu, un skripti, kas nepamana jaunos linkera brīdinājumus kā kļūdas. Pilnās piezīmes ir GitHub laidiena lapā.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.