Rust 1.100: tipo never stabile e cooldown sulle dipendenze in Cargo

Con Rust 1.100.0, annunciato il 12 novembre 2026 dal Rust Release Team, Cargo stabilizza la risoluzione che può rifiutare le versioni dei crate pubblicate da troppo poco tempo e il linguaggio stabilizza il tipo never. Chi ha già Rust installato con rustup si aggiorna con rustup update stable. Per chi mantiene progetti con molte dipendenze, workspace o script di build, le novità di Cargo sono tre: un cooldown da attivare, un avviso sulle dipendenze inutilizzate e una build-dir riorganizzata che può rompere processi esistenti.

Cooldown sulle dipendenze: come si attiva e come si scavalca

La funzione si chiama min-publish-age, detta anche dependency cooldowns. Quando Cargo sceglie le versioni, salta quelle pubblicate da meno del tempo indicato. La ragione, spiega il team nell’annuncio sul blog di Rust, è che i pacchetti malevoli vengono spesso scoperti entro ore o giorni dalla pubblicazione, da scanner automatici o dalla comunità.

Non agisce da sola: si imposta in .cargo/config.toml:

[registry] seguito da global-min-publish-age = "3 days".

Con il cooldown attivo, cargo update dice cosa ha trattenuto. Nell’esempio di Rust compaiono cc v1.11.0 (disponibile la v1.18.0, pubblicata 3 ore prima) e clap 4.6.7 (disponibile la 4.6.9, pubblicata 2 giorni prima).

Se una versione serve subito, il controllo si può escludere per un solo aggiornamento: CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update clap --precise 4.6.9. La versione nuova viene registrata in Cargo.lock e resta lì finché un successivo cargo update non risolve di nuovo le dipendenze.

I limiti del cooldown

• Dipende dal registry, che deve registrare la data di pubblicazione di ogni versione: le versioni senza campo pubtime nell’indice non vengono mai trattenute.
• cargo install ignora l’età minima, sia per il crate installato sia per le sue dipendenze. Serve fissare la versione, ad esempio cargo install [email protected].
• Il team avverte che i cooldown riducono il rischio solo di alcuni attacchi alla supply chain e non bastano da soli: gli aggiornamenti delle dipendenze vanno comunque controllati.

Secondo il team, nel progetto di hardening di crates.io sono previsti il supporto alla quarantena e il rilevamento automatico di rilasci sospetti.

Cargo segnala le dipendenze inutilizzate

Cargo ora mostra l’avviso cargo::unused_dependencies, attivo come warn di default. Indica la riga di Cargo.toml e suggerisce di rimuovere la dipendenza. Fa parte del nuovo sistema di lint di Cargo, controllato dalla tabella [lints.cargo] in Cargo.toml.

L’avviso compare solo se si compilano tutti i target che potrebbero usare una voce. Con cargo check --bin foo non appare nulla per le [dependencies], perché un altro bin potrebbe usarle. Per le dev-dependencies non c’è alcun avviso, dato che non si può garantire di compilare tutti i target di sviluppo. Secondo il team, il lint di rustc unused_crate_dependencies dava falsi positivi con Cargo proprio perché le dipendenze sono condivise tra più target.

Build-dir riorganizzata: attenzione a script e test

La build-dir applica ora l’hash della configurazione di build a tutto il contenuto. Le cartelle seguono la fase di build anziché il tipo di file, e l’hash passa dal nome del file alla cartella padre. Prima non sempre veniva applicato, per vincoli di piattaforma: ne derivavano rebuild in più o mancati e confusione su quali binari o librerie venissero usati, con problemi maggiori condividendo la build-dir tra git worktree.

Rust lo definisce un cambiamento interno, ma avverte che può rompere processi di build e test con workaround per funzioni mancanti o incomplete. In certi casi il workaround non serve più. Soluzioni possibili e nuovi casi d’uso si segnalano in cargo#17287. Il lavoro apre la strada a garbage collection della cache, deduplicazione e condivisione della cache tra workspace e blocchi più granulari.

Il tipo never è stabile, con un cambio che può rompere codice

Il tipo never, scritto !, è ora stabile: secondo il team arriva dopo 10 anni e 5 tentativi di stabilizzazione falliti. Si può nominare ovunque, per esempio in Result<T, !>, mentre prima si poteva già usare e osservare, ad esempio in return o break, e nominare solo nel tipo di ritorno delle funzioni (-> !). Infallible diventa un alias del tipo never, quindi le vecchie API che lo usano sono compatibili con !.

Per rendere possibile questo cambio c’è una modifica che può rompere il codice: nelle edizioni precedenti alla 2024 (2015, 2018, 2021) il fallback del tipo never passa da () a !, come già avviene nella 2024. Di solito non si nota, ma in rari casi, per esempio ignorando il risultato di una funzione che restituisce un parametro generico, può avere effetti, e il compilatore può rilevare più codice irraggiungibile. Se una dipendenza si rompe, il team suggerisce di aggiornarla: dice di aver avvisato con largo anticipo e di aver pubblicato correzioni per crate pubblici.

Allocatori, DropGuard e conjure_zst

• Sono stabilizzate le parti centrali di allocator_api: il trait Allocator permette di definire allocatori personalizzati, usabili per ora con Vec e Box. L’estensione ad altre collezioni e tipi puntatore è ancora da fare, con altre stabilizzazioni attese presto.
• core::mem::DropGuard esegue una closure quando viene lasciato cadere, su qualsiasi uscita (return, ? o panic). Con DropGuard::dismiss si recupera la variabile senza eseguire la closure: serve per API transazionali con rollback.
• std::mem::conjure_zst è la funzione unsafe dedicata a creare un valore di un tipo a dimensione zero, al posto di transmute su () o di MaybeUninit::uninit().assume_init().

Altre API stabilizzate

Le API stabilizzate sono decine, l’elenco completo è nelle note di rilascio. Alcune di uso pratico:

• str::trim_prefix e trim_suffix, con le versioni su slice e Path::trim_prefix;
• Vec::from_fn e bool::toggle;
• Box::take e Box::map, con Rc::map e Arc::map;
• os::windows::process::CommandExt::show_window.