Un import Wasm are nevoie de numele modulului și al simbolului

Un import WebAssembly are o identitate pe care verificarea legării native o poate omite. Când două funcții importate au același nume de simbol, dar aparțin unor module diferite, compilarea și execuția în programul gazdă trebuie să păstreze ambele nume. Verificarea integrării ar trebui să facă distincția observabilă, mai ales când declarațiile se află în crate-uri Rust separate, adică unități de compilare diferite.

Privind din noiembrie 2026, Rust 1.91.0 a fost anunțat la 30 octombrie 2025. Corecția 1.91.1 a urmat la 10 noiembrie, reparând două regresii introduse în 1.91.0. Remedierea Wasm arată de ce o versiune de corecție poate conta pentru o integrare restrânsă, chiar dacă mare parte din codul Rust al aplicației continuă să se compileze.

Numele modulului are un rol propriu

Anunțul corecției explică identificarea funcțiilor importate în Wasm prin numele simbolului și numele modulului Wasm. Atributul Rust #[link(wasm_import_module)] stabilește identitatea modulului pentru un bloc extern. Regresia apărea când același nume de simbol era importat din module Wasm diferite, în mai multe crate-uri Rust. Numele simbolului singur nu putea păstra distincția necesară.

Consecințele raportate includeau eșecuri de compilare cu neconcordanță între modulele de import și selectarea unei funcții greșite la execuție. A doua situație putea produce comportament nedefinit, inclusiv blocări și coruperea datelor fără semnalare. Distincția contează pentru dovezi: eroarea de legare se vede la construire, dar selecția greșită poate lăsa un rezultat aparent reușit care încalcă interfața cu programul gazdă.

Rust 1.91.1 a reparat regresia. Aceeași versiune a corectat și blocarea directorului de rezultate Cargo pe illumos, o problemă separată. Cele două nu justifică afirmația că toate operațiile de legare Rust sau toate construirile concurente erau defecte. Decizia de mentenanță trebuie să identifice condiția raportată care se întâlnește efectiv în compilatorul și ținta produsului.

Propuneți un caz care face selecția greșită vizibilă

Un caz de test propus ar conține două module de import care expun același simbol de funcție. Declarațiile ar fi plasate în crate-uri Rust separate, pentru a acoperi situația raportată. Implementările furnizate de gazdă ar întoarce rezultate distincte și cunoscute, iar testul ar apela ambele funcții prin fișierul Wasm construit. Dacă ambele apeluri ar ajunge accidental la aceeași implementare, verificarea ar eșua clar.

Acesta este un caz propus cu două module și același simbol, nu un test efectuat. Pentru articol nu s-a rulat compilatorul și nu s-a reprodus regresia. Propunerea decurge din condiția de eșec descrisă în anunț. Implementarea exactă trebuie să corespundă țintei aplicației, modului de legare și mediului gazdă înainte ca rezultatul să poată susține o lansare.

Alegeți un comportament simplu, cu rezultat ușor de explicat, fără a reproduce întreaga logică a aplicației. Scopul este expunerea identității importului la trecerea dintre componente. Un calcul complicat poate ascunde dacă eroarea vine din alegerea funcției sau din aritmetică. Rezultatele distincte îi arată evaluatorului ce proprietate trebuie să protejeze verificarea.

Păstrați fișierul generat în lanțul dovezilor. Un test care apelează doar înlocuitori nativi poate demonstra aritmetica exemplului fără să folosească importuri Wasm. Nici inspectarea declarațiilor fără instanțierea fișierului relevant nu garantează observarea unei asocieri greșite la execuție. Dovezile alese ar trebui să ajungă la etapa în care defectul raportat poate deveni observabil.

Separarea între crate-uri face parte din caz

Mutarea tuturor declarațiilor într-un singur crate pentru simplificare poate elimina o condiție esențială. Problema istorică trecea explicit granițele dintre crate-uri. Păstrați structura în cazul propus și explicați de ce există. Altfel, un exemplu mic reușit poate crea încredere nejustificată într-un produs ale cărui declarații rămân separate între dependențe.

Notați versiunea compilatorului, ținta și versiunile dependențelor relevante împreună cu orice rezultat ulterior. Dacă interfețele generate sau configurația gazdei furnizează numele importurilor, păstrați și versiunile lor. Scopul este reproducerea comportamentului, nu un inventar lung fără utilitate. O actualizare viitoare ar trebui să poată fi comparată cu ultimul fișier funcțional și cu configurația gazdei sale.

Verificați și ce furnizează efectiv gazda. Un modul absent, un simbol scris greșit și pierderea identității de către compilator sunt eșecuri diferite. Cazul propus ar trebui să arate suficient de clar asocierea dorită pentru a le distinge. Altfel, eroarea integrării poate fi atribuită unei regresii istorice care nu mai există în compilatorul actual.

Subiectul diferă de articolul anterior despre compatibilitatea ABI a interfețelor Wasm generate. Acolo contează convențiile de apelare și potrivirea apelantului cu interfața generată. Aici contează ce funcție importată este selectată când modulele au nume diferite. Reprezentarea corectă a argumentelor nu dovedește alegerea corectă a importului, iar alegerea corectă nu verifică toate detaliile convenției de apelare.

Majoritatea aplicațiilor cer o evaluare mai restrânsă

Cel mai puternic contraargument privește expunerea. O aplicație fără funcții Wasm importate nu este expusă acestei regresii. Nici una fără combinația dintre același simbol, module diferite și crate-uri separate nu trebuie să primească automat un test special doar pentru că folosește Rust sau WebAssembly. Stabiliți mai întâi dacă există condiția raportată.

Pentru o construire afectată, corecția istorică stabilește unde s-a reparat problema, nu recomandă păstrarea nelimitată a versiunii 1.91.1 în noiembrie 2026. Alegeți un compilator potrivit și cu suport în prezent și analizați schimbările relevante intervenite. Fixarea temporară la o versiune cunoscută poate limita riscul, dar renunțarea la fixare cere un responsabil și dovezi.

Verificările integrării ar trebui să fie proporționale cu interfețele promise. Un caz dedicat merită când identitatea importurilor contează efectiv și suita obișnuită nu o verifică. Dacă testele existente disting deja ambele implementări prin fișierul livrat, dublarea cazului poate aduce puțin. Analizați ce demonstrează dovezile înainte de extinderea suitei.

Pentru mentenanță software, cereți întâi o evaluare a expunerii: forma importurilor, compilatorul care a construit fișierul și verificarea asocierii cu gazda. Dacă trebuie adăugate verificări, faceți vizibile numele modulului și al simbolului în rezultatul așteptat. Compilarea nativă reușită nu poate închide singură o întrebare specifică Wasm.