Rust 1.100 apporte le type never, les allocateurs et des lints Cargo

Le projet Rust a publié Rust 1.100.0 le 12 novembre 2026. Cette version rend le type never stable, ouvre le cœur de l'API des allocateurs personnalisés et apprend à Cargo à signaler les dépendances inutilisées. Le changement du type never est aussi un changement cassant, et les notes de version le rangent sous "Compatibility Notes". Des projets de n'importe quelle édition peuvent désormais échouer à compiler là où ils compilaient avant.

L'annonce sur le Rust Blog indique que le type never a mis 10 ans et 5 tentatives ratées pour devenir stable. LWN.net a mis en avant les trois mêmes changements : le type never, le cœur de l'Allocator API et le rapport de Cargo sur les dépendances inutilisées. Les utilisateurs de Rust mettent à jour avec rustup update stable.

Les nouveautés de Rust 1.100

Le type never, noté !, est le type d'un code qui ne se termine jamais, comme un panic! ou une boucle infinie. Jusqu'ici, il ne pouvait apparaître que comme type de retour d'une fonction. Notre guide du type never de Rust l'explique en détail, et notre article d'août couvrait la pull request qui l'a rendu stable.

Le tableau ci-dessous s'appuie sur le billet de blog, les notes de version sur GitHub et le changelog de Cargo.

Changement	Ce qu'il fait	Qui le remarque
Type never !	Utilisable partout, comme dans Result<T, !> ; Infallible devient un alias de !	Le code qui s'appuyait sur l'ancien repli
Repli de type	Un type inconnu dans une branche divergente devient !, et non (), dans toutes les éditions	Les anciens crates jamais passés à l'édition 2024
Allocator API	Allocator, Global, System, ainsi que Vec::new_in, Box::new_in et des méthodes similaires	Le code qui gère sa propre mémoire
cargo::unused_dependencies	Avertit quand une dépendance de Cargo.toml n'est jamais utilisée	Tous les projets Cargo
Âge minimal de publication	Cargo peut ignorer les versions de crates plus récentes qu'un âge donné	Les équipes inquiètes des attaques sur la chaîne d'approvisionnement
Organisation du dossier de build	Les fichiers de build intermédiaires changent de place	Les scripts qui lisent directement le dossier target de Cargo
i686-pc-windows-gnu	Désormais Tier 2 sans outils hôtes	Les utilisateurs de Windows 32 bits

Le changement pour Windows 32 bits a été annoncé en octobre, comme l'explique notre article sur les cibles i686. Cette version stabilise aussi de petites fonctions utilitaires, comme bool::toggle, Vec::from_fn et str::trim_prefix.

Test de Tech AI Wire : Rust 1.99.1 contre 1.100.0

Lors d'un test de Tech AI Wire sous macOS 26.6.2, les mêmes petits projets ont tourné dans les images Docker officielles rust:1.99-slim et rust:1.100-slim. Les deux reposent sur Debian 13 en arm64. Les images indiquaient rustc 1.99.1 et rustc 1.100.0.

Le premier projet utilisait l'édition 2021 et ce code :

fn make<T: Default>() -> Result<T, ()> {
    Ok(T::default())
}

fn main() -> Result<(), ()> {
    make()?;
    Ok(())
}

Rien n'indique au compilateur ce qu'est T, il se rabat donc sur un type par défaut. Voici ce qu'a fait chaque version :

Code	Rust 1.99.1	Rust 1.100.0
Tel quel	Erreur du lint dependency_on_unit_never_type_fallback	Erreur E0277 : "the trait bound !: Default is not satisfied" (la contrainte de trait !: Default n'est pas satisfaite)
Avec #![allow(dependency_on_unit_never_type_fallback)]	Compile et s'exécute	Toujours l'erreur E0277 ; le lint "has been removed" (a été supprimé)
Avec make::<()>()?	Compile et s'exécute	Compile et s'exécute

La ligne du milieu est le piège. Un crate qui faisait taire l'avertissement sous 1.99 y compile, puis échoue sous 1.100. Rust 1.100 explique que le lint a été supprimé parce que "the code warned by this lint no longer compiles" (le code signalé par ce lint ne compile plus). Seul le fait de nommer le type règle le problème.

Le test d'allocateur personnalisé enveloppait l'allocateur global pour compter les requêtes. Sous 1.99.1, il échouait avec l'erreur E0658, "use of unstable library feature allocator_api". Sous 1.100.0, il tournait en stable. Un Vec de 1 000 nombres plus un Box ont produit 10 appels d'allocation pour 16 356 octets.

Test de Tech AI Wire : les deux nouveaux contrôles de sécurité de Cargo

Un crate (un paquet Rust) déclarait itoa et memchr comme dépendances, mais n'utilisait que itoa. Sous 1.100, cargo build a affiché "warning: unused dependency memchr". Régler unused_dependencies = "deny" sous [lints.cargo] en a fait une erreur, et le build s'est arrêté. Une dev-dependency jamais utilisée n'a reçu aucun avertissement. Pas plus que cargo check --bin unused, qui vérifie une seule cible. Les deux cas correspondent à des exemptions listées dans le billet de blog. Rust 1.99.1 ignorait la table [lints.cargo] avec un avertissement "unused manifest key".

L'âge minimal de publication retarde les toutes nouvelles versions de crates, ce que le billet de blog appelle des "dependency cooldowns". L'attente laisse aux autres le temps de repérer une mauvaise version avant que votre build ne l'intègre. Avec global-min-publish-age = "3 days" sous [registry], Cargo a verrouillé cc en 1.11.1. Il a affiché "available: v1.11.2, published 2 hours ago". Sans ce réglage, Cargo a choisi 1.11.2. Avec 30 jours, la résolution a échoué, car cargo add avait déjà inscrit 1.11.1 comme version minimale. Cargo a suggéré d'abaisser l'exigence à "1.8.0" ou de définir CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow.

Ce que cela change pour les développeurs

• Compilez chaque crate avec 1.100 avant de mettre à jour la CI. Le code des éditions plus anciennes est le plus susceptible de casser. Cherchez allow(dependency_on_unit_never_type_fallback), car ce code échoue sous 1.100.
• Corrigez les erreurs de repli en nommant le type. La suggestion du compilateur lui-même, comme make::<()>(), a fonctionné sur les deux versions pendant le test.
• Activez l'âge minimal de publication dès maintenant. Trois jours de global-min-publish-age dans .cargo/config.toml coûtent peu. Réglez-le avant de lancer cargo add, car cette commande écrit la version qu'elle choisit dans Cargo.toml.
• Nettoyez les dépendances inutilisées avant de les interdire. Commencez par le niveau par défaut warn, supprimez ce qu'il trouve, puis passez à deny dans la CI.
• Lisez les Compatibility Notes. Elles mentionnent aussi la suppression des motifs box, Unicode 18.0.0 et des contrôles plus stricts des target features ARM.
• Arrêtez de lire directement les dossiers de build de Cargo. Leur organisation a changé dans 1.100, et le changelog de Cargo indique que les outils doivent plutôt utiliser les messages JSON de Cargo.