Rust 1.99 : le programme de salle ne joue pas le mouvement debug

Le programme de salle tient sur une feuille. Tu le lis dans le hall, debout, avant que ça commence. Dedans, les mouvements qu'on te promet d'entendre : des fonctions que tu peux enfin écrire, trois façons de mesurer un pointeur, et une recommandation sur une fuite qu'il ne faudrait plus rattraper. La partition, elle, est sur le pupitre. Elle a les mêmes thèmes. Elle a aussi des barres que la feuille du hall ne recopie pas, dont un mouvement qui porte le nom debug et qui, pour l'instant, joue exactement le même tempo qu'un autre.

Le 1er octobre 2026, l'équipe des sorties de Rust annonce Rust 1.99.0. Si tu as déjà rustup, la ligne est rustup update stable. Le billet te renvoie aux notes détaillées. Je les ai lues à l'ancre version-1990-2026-10-01. Le billet, après sa liste, dit qu'il y a d'autres changements, et il pointe vers Rust, Cargo et Clippy. Clippy, je ne l'ai pas ouvert.

Ce que le programme imprime en gros

Le premier mouvement stabilise l'écriture, en Rust, de fonctions variadiques en ABI « C » et « C-unwind ». Rust savait déjà appeler une fonction variadique définie dehors, le billet cite libc::printf. Avec 1.99, ces fonctions peuvent être écrites dans le langage. L'exemple du billet est une unsafe extern "C" fn sum(mut args: ...) -> i32, qui lit deux i32 avec args.next_arg::<i32>(). Les commentaires SAFETY sont dans l'exemple. Je ne les retire pas. Le type de ... est VaList, compatible d'ABI avec le va_list du C selon les cibles. Ce qu'on a le droit d'y lire est gardé par le trait VaArgSafe. Le détail est renvoyé au Reference. La même sortie stabilise aussi des fonctions variadiques naked pour des ABI qui ne sont pas « C », et celles-là doivent être écrites en assembleur inline.

Le deuxième mouvement règle ce qu'il en coûte, côté sûreté, de demander la taille et l'alignement à un pointeur brut. Pour les types Sized, le billet dit que c'est trivialement sûr, et déjà possible en stable. Pour les types qui ne sont pas Sized, la question est tranchée en stabilisant trois fonctions : Layout::for_value_raw, mem::size_of_val_raw, mem::align_of_val_raw.

Le troisième ne change pas le langage. Le billet le dit : aucun changement de sémantique. La documentation de Box::leak déconseille maintenant les motifs qui libèrent cette mémoire plus tard. La raison écrite : ces motifs interagissent mal avec des optimisations présentes et avec d'autres, possibles, et c'est particulièrement gênant avec la stabilisation à venir des allocateurs personnalisés. À la place, le billet indique Box::into_non_null ou Box::into_raw. La même consigne vaut pour les autres fonctions leak de la bibliothèque standard. « À venir ». Je n'en fais pas un jour.

La liste des API est la même des deux côtés

Le billet et les notes impriment la même liste stabilisée. Je la pose une fois. IntoIterator pour Box<[T; N]>, pour la référence, et pour la référence mutable. VecDeque::retain_back. core::ffi::VaList. Box::into_non_null et Box::from_non_null. Vec::into_parts et Vec::from_parts. Les trois fonctions de taille et d'alignement déjà nommées. String::from_utf8_lossy_owned. string::FromUtf8Error::into_utf8_lossy. FusedIterator pour StepBy. std::fs::set_times et std::fs::set_times_nofollow.

Si tu t'arrêtes au programme de salle, tu as cette liste, les trois mouvements, et un renvoi. La partition continue.

Côté Cargo, les notes ajoutent un profil intégré nommé debug. La phrase dit que c'est une préparation : un jour, le profil dev s'éloignera du débogage, pour itérer plus vite, et debug sera l'endroit du vrai débogage. Pour l'instant, il n'y a pas de différence entre dev et debug. Le mouvement est écrit. Il joue le même tempo que celui d'à côté. Je ne le vends pas comme un réglage nouveau que tu sentirais en changeant le nom.

La barre d'après ne concerne que les membres d'espace de travail en édition 2024 ou plus. Ils peuvent maintenant surcharger le champ default-features d'une dépendance héritée. L'exemple des notes : serde = { workspace = true, default-features = false } coupe les fonctionnalités par défaut même si la définition de l'espace de travail les allume. Sur les éditions d'avant, default-features = false est ignoré, avec un avertissement. Deux éditions, deux lectures du même mot.

La troisième barre Cargo : la compilation incrémentale est désactivée par défaut dans CI. CI, ici, est détecté par la variable d'environnement CI. Le programme de salle ne le dit pas. Si ta machine n'a pas cette variable, les notes ne disent pas que ton incrémental a bougé.

Les barres que la feuille du hall ne recopie pas

Les bibliothèques, dans les notes, optimisent mieux l'itération sur RangeInclusive, les plages a..=b, dans certaines circonstances. L'effet de bord : le comportement d'une plage déjà épuisée comme itérateur a changé. start() et end() peuvent renvoyer d'autres valeurs, et s'en servir comme index de slice peut changer aussi. Les notes disent que ces comportements n'étaient pas garantis stables, donc que ce n'est pas considéré comme un changement cassant. Je n'invente pas la nouvelle valeur. Je recopie la réserve.

Rustdoc gagne un lint unused_footnote_definition. Et un filtrage des implémentations de traits annonce des gains de 20 % en moyenne, jusqu'à 40 % sur certains crates réels. C'est rustdoc. Ce n'est pas le temps de cargo build de ton projet, sauf si les notes le disaient. Elles ne le disent pas.

Le support de plate-forme promu dans cette version, dans les notes : riscv64-unknown-linux-musl, palier 2, avec les outils hôtes. Une cible. Je n'en ajoute pas.

Côté compatibilité, les modules d'entiers historiques sont entièrement dépréciés. L'exemple des notes : std::i32::MAX se lit i32::MAX. no_mangle_generic_items devient une erreur dure. Les invariants de Pin::new_unchecked ont un peu changé. Je m'arrête sur l'adverbe : la note ne me donne pas le nouvel énoncé dans la ligne que j'ai lue. Et la ligne Box::leak des notes de compatibilité est la forme courte de ce que le billet raconte : dire aux gens d'éviter le dé-leak.

Tout en bas, les changements internes. Les notes préviennent qu'ils ne touchent aucune interface publique. La seule puce : le passage à LLVM 23. Je ne traduis pas ça en écart de performance sur ton code. La partition dit que ce n'est pas une interface.

✍️ À toi : le rustc -V que ton projet lance vraiment, et si ta CI pose la variable CI. Le programme de salle a une version. Ta machine a un binaire, et peut-être une variable.

Le 1er octobre, le hall t'annonce des fonctions C à arguments variables, trois mesures sur pointeur brut, et une documentation qui déconseille de reprendre la mémoire après Box::leak, sans changer la sémantique. La liste stabilisée est la même sur la feuille et sur la partition. Le profil debug est écrit, et il ne diffère pas encore de dev. L'incrémental, lui, se tait quand la variable CI est là, et cette barre-là n'est pas dans le programme qu'on te tend à l'entrée.