Quinze jours après la sortie de Rust 1.99.0, l’équipe du langage a publié le 15 octobre une version corrective, Rust 1.99.1. Pas de nouveauté ici, mais trois régressions corrigées, dont une erreur de compilation du code qui renvoie un booléen à travers l’interface C. Si vous maintenez du code FFI ou si vous ciblez l’UEFI, la mise à jour mérite d’être faite rapidement.
En toile de fond, une autre annonce du blog officiel concerne tous ceux qui compilent encore pour Windows 32 bits : avec Rust 1.100, le compilateur ne pourra plus s’installer sur ces machines.
Plan de l'article
Ce que corrige Rust 1.99.1 #
D’après l’annonce de Rust 1.99.1 sur le blog du projet, la version corrige trois régressions apparues dans des versions précédentes. Pour l’installer, la commande habituelle suffit : rustup update stable.
À lire SIREN, SIRET, NIC, code APE : le guide pour s’y retrouver
Un booléen qui ne valait plus seulement 0 ou 1
C’est le correctif le plus sérieux. Sur x86_64, une fonction Rust qui renvoyait un bool via FFI pouvait laisser les bits 1 à 7 du registre de retour indéterminés. Résultat : le code appelant, côté C par exemple, pouvait lire une valeur brute différente de 0 ou de 1.
Ce genre de bug est sournois. Un test du type if (resultat == 1) peut échouer alors que Rust a bien renvoyé « vrai ». L’équipe a de nouveau marqué ce type de retour pour une extension à zéro, comme l’exige l’ABI. Si vous avez observé des comportements bizarres sur des bibliothèques Rust appelées depuis C, C++ ou Python via ctypes depuis la 1.99.0, c’est la première piste à vérifier.
Le symbole wcslen manquant
Certaines cibles se heurtaient à des erreurs d’édition de liens à cause d’un symbole wcslen introuvable. L’origine est une optimisation de LLVM, la passe loop-idiom-wcslen, qui peut insérer des appels à cette fonction alors que la cible ne la fournit pas forcément. Les cibles UEFI étaient cassées pour tout projet utilisant std, car certains de ces appels se trouvaient dans la bibliothèque standard précompilée. La fonction est désormais présente dans la bibliothèque compiler-builtins, en solution de repli.
rust-lld sur macOS
Dernier correctif : sur macOS, l’éditeur de liens rust-lld pouvait échouer à charger libLLVM lorsque le compilateur était appelé sans passer par le proxy rustup. C’est un cas fréquent dans les environnements de build qui pointent directement vers un toolchain. rust-lld est maintenant construit avec une entrée rpath vers le dossier qui contient libLLVM.dylib.
À lire Réputation IP de l’expéditeur : la protéger et l’améliorer
Rappel : ce qu’avait apporté Rust 1.99.0 #
La version corrective vient compléter une version mineure bien remplie, publiée le 1er octobre. Comme le détaille l’annonce de Rust 1.99.0, sa nouveauté principale est la stabilisation des fonctions variadiques avec les ABI « C » et « C-unwind ». Rust savait déjà appeler des fonctions variadiques externes comme printf ; il est maintenant possible de les écrire en Rust. Les arguments sont lus via le type VaList, compatible avec le va_list du C.
La 1.99.0 stabilise aussi trois fonctions qui donnent la taille et l’alignement à partir de pointeurs bruts (Layout::for_value_raw, mem::size_of_val_raw et mem::align_of_val_raw), ainsi qu’une série d’API, parmi lesquelles Vec::into_parts, Vec::from_parts, Box::into_non_null ou std::fs::set_times.
Un changement de doctrine sur Box::leak
Autre point à retenir pour les auteurs de code unsafe : la documentation de Box::leak déconseille désormais de « récupérer » plus tard la mémoire fuitée pour la libérer. Selon l’équipe, ce schéma interagit mal avec les optimisations du compilateur, actuelles et à venir, en particulier avec la stabilisation prochaine des allocateurs personnalisés. Il faut préférer Box::into_raw ou Box::into_non_null. La sémantique du langage ne change pas, mais c’est le bon moment pour faire le ménage.
Windows 32 bits : la fin des outils de développement #
Le 2 octobre, l’équipe du compilateur a publié un billet sur la rétrogradation des cibles Windows i686. À partir de Rust 1.100, la cible i686-pc-windows-msvc passera de « Tier 1 avec outils hôtes » à « Tier 1 sans outils hôtes », et i686-pc-windows-gnu de « Tier 2 avec outils hôtes » à « Tier 2 sans outils hôtes ».
À lire SPF, DKIM, DMARC : comprendre l’authentification des emails
Concrètement, la bibliothèque standard continuera d’être distribuée pour ces cibles, et la cible MSVC restera testée en intégration continue. En revanche, le compilateur lui-même ne sera plus fourni pour ces plateformes : il ne sera plus possible d’installer un toolchain sur un hôte Windows 32 bits. Pour produire des binaires 32 bits, il faudra faire de la compilation croisée depuis un hôte encore pris en charge, typiquement un Windows 64 bits.
L’équipe justifie ce choix par la quasi-disparition de ces machines de développement et par des difficultés techniques : des binaires du compilateur qui plantaient une fois construits pour la cible i686 MSVC, et des manques de mémoire lors de la construction de LLVM avec la chaîne GNU. Les autres plateformes 32 bits ne sont pas concernées.
Que faire dès maintenant #
Pour la plupart des projets, la réponse tient en une commande : rustup update stable. Si votre CI fige une version précise, pensez à passer à 1.99.1, surtout si vous exposez des fonctions à du code C.
Si vous livrez encore un exécutable Windows 32 bits, anticipez dès aujourd’hui : ajoutez la cible avec rustup target add i686-pc-windows-msvc sur votre machine ou votre runner 64 bits, et vérifiez que votre build croisé passe avant l’arrivée de Rust 1.100.
À lire Guide pratique pour comparer les opérateurs eSIM : les critères qui comptent vraiment
Questions fréquentes #
Rust 1.99.1 ajoute-t-il des fonctionnalités ?
Non. C’est une version corrective : elle ne fait que réparer trois régressions (FFI bool sur x86_64, symbole wcslen, rust-lld sur macOS).
Mon programme 32 bits pour Windows va-t-il cesser de fonctionner ?
Non. Les binaires existants ne sont pas touchés et la bibliothèque standard i686 reste distribuée. Ce qui disparaît avec Rust 1.100, c’est la possibilité d’installer le compilateur sur un Windows 32 bits.
Comment savoir si je suis concerné par le bug des booléens ?
Vous l’êtes potentiellement si vous compilez en 1.99.0 sur x86_64 des fonctions extern "C" qui renvoient un bool. Passer en 1.99.1 règle le problème.
