Rust 1.100 : type never stable, cooldown dans Cargo

Ce qui se passe

Rust 1.100.0 est sorti le 12 novembre. Deux changements dépassent le cercle des habitués du langage : la stabilisation du type never, et un délai minimal de publication dans Cargo, qui écarte les versions trop fraîches.

rustup update stable

Le type never, et sa rupture

Le type ! est celui des expressions qui ne produisent jamais de valeur : return, break, std::process::exit. Il se convertit en n'importe quel autre type, ce qui permet à une branche de match de sortir par un return sans casser le typage. On pouvait déjà l'écrire en type de retour (-> !) ; on peut désormais le nommer partout, par exemple Result<T, !> pour une erreur impossible. Il aura fallu dix ans et cinq tentatives de stabilisation.

Infallible devient un alias de !, ce qui rend compatibles toutes les API qui l'utilisaient. Le prix est une rupture : dans les éditions 2015, 2018 et 2021, le type de repli du never passe de () à !, comme c'était déjà le cas en édition 2024. L'effet est rare — typiquement, du code qui ignore le résultat d'une fonction dont le retour est un paramètre générique — et le compilateur peut détecter davantage de code inatteignable. Des avertissements de compatibilité étaient émis depuis longtemps, et des correctifs ont été publiés pour les crates publiques touchées : si une dépendance casse, mettez-la à jour avant de chercher plus loin.

Cargo : le délai de publication

Une version malveillante est souvent repérée en quelques heures ou quelques jours, par des analyseurs ou par la communauté. Cargo peut maintenant attendre cette fenêtre :

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

cargo update retient alors la version compatible la plus récente publiée depuis au moins trois jours, et affiche ce qu'il a laissé de côté avec l'âge de la version écartée. Pour une mise à jour urgente, une variable d'environnement lève le contrôle sur une seule commande :

CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update clap --precise 4.6.9

La version forcée est inscrite dans Cargo.lock et y reste jusqu'au prochain cargo update qui la réévalue.

Les limites :

• une version dont l'index ne porte pas de champ pubtime n'est jamais mise en attente ;
• cargo install ignore le délai, pour la crate installée comme pour ses dépendances : épinglez avec cargo install foo@1.2.3 ;
• c'est une protection partielle, pas une relecture des mises à jour. La suite est prévue dans l'objectif « crates.io supply chain hardening » : quarantaine et détection automatique de versions suspectes.

Le principe est le même que le cooldown arrivé dans Composer 2.11 (fiche du 4 novembre).

Le reste de la version

• API Allocator, stabilisée dans son noyau : allocateurs personnalisés pour Vec et Box (Vec::new_in, Box::new_in, Vec::with_capacity_in…).
• core::mem::DropGuard : exécute une fermeture à la sortie de portée, quel que soit le chemin (return, ?, panique) ; DropGuard::dismiss rend la valeur sans l'exécuter, de quoi écrire un tout-ou-rien avec retour arrière.
• std::mem::conjure_zst, fonction unsafe, la manière désormais officielle de créer une valeur d'un type de taille nulle.
• Lint cargo::unused_dependencies, en avertissement par défaut et réglable dans [lints.cargo]. Il ne s'affiche que si toutes les cibles susceptibles d'utiliser la dépendance sont compilées, et jamais pour les dev-dependencies.
• Nouvelle organisation de build-dir : le hash de configuration s'applique partout, d'où moins de recompilations inutiles, mais les scripts qui contournaient l'ancienne disposition peuvent casser (voir cargo#17287).
• Parmi les API stabilisées : bool::toggle, Vec::from_fn, str::trim_prefix et str::trim_suffix, Box::map, Rc::map, Arc::map, Box::take.

Source : Rust Blog, en anglais.