Le projet gccrs est un effort ambitieux commencé en 2014 pour implémenter un compilateur Rust au sein de la collection de compilateurs GNU (GCC). Même si la tâche est loin d'être achevée, des progrès ont été réalisés depuis la précédente couverture de LWN, selon les rapports du projet. Entre-temps, une autre approche hybride et plus mature de la génération de code GCC Rust est disponible dans rustc_codegen_gcc.En 2022, l'objectif de gccrs était d'être inclus dans la version 13 de GCC, mais cette attente n'a pas été satisfaite. L'équipe vise actuellement l'inclusion dans GCC 14 (probablement à la mi-2024), à en juger par son rapport mensuel de novembre 2023.
Le 13 octobre, Arthur Cohen a donné une conférence intitulée "The road to compiling the standard library with gccrs" à EuroRust 2023. Dans sa présentation, Cohen a donné quelques informations générales sur gccrs mais s'est surtout concentré sur le travail effectué récemment pour compiler la bibliothèque standard de Rust, et pourquoi gccrs ne peut pas encore le faire.
Gccrs cible une version spécifique de Rust, 1.49, sortie fin 2020, plutôt que d'essayer de suivre le développement rapide du langage Rust. Cette version a été choisie parce qu'elle est la plus récente avant le support des const generics, qui ont été introduits dans la version 1.50. Cependant, M. Cohen a regretté dans son exposé que le projet n'ait pas été en mesure d'ignorer les const generics après tout, car ils sont utilisés dans la bibliothèque standard, même dans la version 1.49. Ils ont été "stabilisés" pour une disponibilité générale dans la version 1.50, mais il y a une utilisation interne de la bibliothèque standard dans les versions antérieures également. Cependant, les const generics ont été entièrement implémentés depuis, et ce problème n'est plus un obstacle.
Beaucoup d'attention est portée à ce que gccrs ne devienne pas un "superset" de Rust, comme l'a dit Cohen. Le projet veut s'assurer qu'il ne crée pas un langage spécial "GNU Rust", mais essaie plutôt de reproduire le résultat de rustc - les bugs, les bizarreries et tout le reste. Les suites de tests de Rust et de GCC sont utilisées à cette fin.
La bibliothèque standard de Rust se compose d'un certain nombre de "crates", qui sont les noms des logiciels dans le jargon de Rust. Cohen a expliqué que gccrs travaille sur la compilation des deux crates les plus importants : core et alloc. Le crate core est la base de la bibliothèque standard, mettant en œuvre des fonctionnalités telles que les types primitifs et les macros ; alloc traite de l'allocation de la mémoire du tas et de divers types de conteneurs.
Actuellement, gccrs n'est pas en mesure de compiler ces crates en raison de diverses lacunes, telles qu'un comportement incorrect dans la résolution des noms de macros et un support incomplet des macros de décorateurs. L'absence d'un vérificateur d'emprunts (discuté plus bas), bien que ne bloquant pas la compilation, signifie que le compilateur ne peut pas vérifier correctement la sécurité du code. Un obstacle supplémentaire est constitué par l'absence d'éléments intrinsèques du compilateur dans GCC. Rustc utilise certains intrinsèques fournis par LLVM qui ne sont pas supportés par GCC, ce qui signifie que l'équipe gccrs doit passer du temps à les implémenter dans GCC.
Un autre exposé a été donné par Pierre-Emmanuel Patry au chaudron des outils GNU en septembre 2023. Il s'est principalement concentré sur les progrès vers l'inclusion dans GCC 14 ainsi que sur les macros, qui semblent être une question interdépendante parce que l'approche pour implémenter les macros procédurales nécessite des changements dans le système de construction de GCC. Les macros procédurales sont des macros de type fonction qui émettent des flux de jetons plutôt que du texte de code source brut comme les macros C ou C++. Elles sont implémentées dans une caisse intégrée appelée proc_macro. Ces macros sont notoirement difficiles à mettre en œuvre, mais elles sont également puissantes ; elles constituent le cœur de fonctionnalités telles que les décorateurs #[attribute] et #[derive()], et peuvent être utilisées pour créer des langages spécifiques à un domaine, évalués à la compilation.
Lors de la conférence GNU Cauldron, Patry a également mentionné que gccrs avait plus de 800 commits qui attendaient d'être transférés à GCC.
Tirer parti de l'écosystème GCC
L'exposé de Cohen à EuroRust a mis en évidence le fait que l'une des principales raisons pour lesquelles gccrs est développé est de pouvoir tirer parti des modules de sécurité de GCC. Il existe une large gamme de plugins GCC qui peuvent aider au débogage, à l'analyse statique ou au durcissement ; ces plugins travaillent sur la représentation intermédiaire de GCC. Gccrs a l'intention de soutenir les flux de travail où les développeurs peuvent réutiliser ces plugins avec du code Rust. À titre d'exemple, Cohen a mentionné que "les programmeurs C oublient de fermer leurs descripteurs de fichiers depuis 40 ans, [donc] il y a beaucoup de plugins pour rattraper cela". Gccrs vise à permettre aux programmeurs Rust d'utiliser les plugins GCC et les analyseurs statiques existants pour détecter les bogues dans le code non sécurisé.
M. Cohen a dressé une liste de choses pour lesquelles Gccrs est déjà utile. Selon lui, la communauté Sega Dreamcast homebrew utilise gccrs pour créer de nouveaux jeux pour la console de jeu Dreamcast, et les plugins GCC peuvent déjà être utilisés pour effectuer une analyse statique sur du code Rust non sécurisé. L'intérêt de la communauté Dreamcast provient du fait que le backend LLVM de rustc ne supporte pas l'architecture Hitachi SH-4 de la console, alors que GCC le supporte ; même dans son état incomplet, gccrs est utile pour ce cas d'utilisation embarqué.
En outre, il a mentionné que l'effort de gccrs a révélé certaines caractéristiques non spécifiées du langage, telles que Deref et la résolution des noms de macro ; en réponse, le projet a été en mesure de contribuer à des ajouts à la spécification de Rust. Actuellement, Rust n'a pas de spécification formelle, mais des travaux sont en cours pour en créer une, comme le propose la RFC 3355. "Les membres de gccrs veulent participer à cet effort, a déclaré M. Cohen.
Une autre raison d'être de gccrs est Rust for Linux, l'initiative visant à ajouter le support de Rust au noyau Linux. Cohen a déclaré que le noyau Linux est une motivation clé pour le projet parce qu'il y a beaucoup de personnes qui préfèrent que le noyau soit compilé uniquement par la chaîne d'outils GNU.
Choses en cours de développement
Il manque encore à Gccrs de nombreuses fonctionnalités de base. Cohen a énuméré plusieurs fonctionnalités importantes, telles que async/await, les intrinsèques LLVM qui sont absentes dans GCC, et la macro format_args !() utilisée par les macros de sortie telles que println !(). Le vérificateur d'emprunts, qui est un sous-système du compilateur qui applique les règles de référence du langage, est une fonctionnalité clé de Rust que gccrs devra fournir. Cohen a brièvement mentionné que la solution probable est un projet séparé de vérificateur d'emprunts appelé Polonius, et a dit que Gccrs l'intégrera probablement quelques mois plus tard. Le contributeur Jakub Dupak a fait des progrès à ce sujet au cours des derniers mois.
Polonius est une bibliothèque qui implémente un vérificateur d'emprunts qui est sémantiquement équivalent au vérificateur (pas tout à fait impeccablement implémenté) dans rustc aujourd'hui, en abordant le calcul des durées de vie des références avec un algorithme radicalement différent. Polonius vise à résoudre un jour les lacunes et les cas particuliers du vérificateur d'emprunts actuel de rustc. Une fois qu'il aura atteint sa maturité, il est probable que Rustc lui-même l'adoptera à l'avenir.
Selon le rapport mensuel de gccrs pour novembre 2023, le travail a commencé sur la macro format_args !(). Cette macro d'aide est responsable de la construction des paramètres pour d'autres macros de formatage de chaînes. Elle implique les traits Display et Debug, et est nécessaire pour préparer les arguments qui sont ensuite transmis à d'autres macros telles que format !() et println !(). Sans format_args !(), un programme Rust ne peut pas créer de sortie formatée ; cette fonctionnalité est donc nécessaire pour que gccrs puisse compiler un programme "Hello, World".
rustc_codegen_gcc
Il existe un autre projet Rust basé sur GCC, appelé rustc_codegen_gcc, qui est plus mature et dont la portée est plus limitée que celle de gccrs. Il ne s'agit pas d'une implémentation complète d'un compilateur Rust à partir de la base ; à la place, il utilise la bibliothèque libgccjit pour s'accrocher à une API du backend LLVM utilisé par rustc. Cette approche permet d'effectuer une grande partie de la compilation avec rustc et de passer à GCC à un stade ultérieur. Malgré le terme "JIT" (juste à temps) dans le nom de la bibliothèque, rustc_codegen_gcc est destiné à la compilation en avance de phase. Son objectif principal est de permettre la génération de code Rust sur des plateformes non supportées par LLVM.
Depuis octobre 2023, rustc_codegen_gcc peut désormais compiler Rust pour Linux sans aucun correctif supplémentaire. Au cours de l'année écoulée, le projet semble avoir bien progressé sur de nombreux fronts ; par exemple, il a ajouté la prise en charge des opérations SIMD (instruction unique, données multiples) et l'optimisation du temps de liaison, deux éléments qui avaient été précédemment identifiés comme des causes d'échec des tests. Cohen a fait référence à rustc_codegen_gcc à plusieurs reprises dans son exposé à EuroRust, encourageant les participants à l'utiliser au lieu de gccrs pour l'instant. En fait, il est déjà intégré dans le référentiel du langage Rust.
Rust pour Linux
Actuellement, le projet Rust pour Linux fournit de la documentation sur l'utilisation de rustc ou de rustc_codegen_gcc pour construire du code Rust pour le noyau. Le noyau contient également de la documentation sur les versions minimales supportées de divers outils de construction, y compris les compilateurs. Pour rustc, la version est considérée comme une correspondance exacte, plutôt qu'un minimum. La version de rustc actuellement supportée est la 1.73.0 (publiée en octobre 2023), bien plus récente que la 1.49 visée par gccrs. La prise en charge de Rust pour Linux est également un objectif déclaré de gccrs, mais en raison de cet écart important, il semble que l'on en soit encore loin.
Gccrs a bien progressé au cours de l'année écoulée depuis la dernière fois que nous l'avons examiné : le dépôt a bien plus de 3 000 commits depuis le 1er janvier 2023. Cependant, il n'est pas encore dans un état utilisable pour presque tous les objectifs pratiques, car en tant qu'implémentation complète à partir de la base, gccrs est beaucoup plus ambitieux dans sa portée que rustc_codegen_gcc. Ce dernier est déjà intégré au dépôt Rust en amont et est utilisé dans le monde réel avec Rust pour Linux. Nous ne sommes pas encore dans un monde avec de multiples implémentations d'un compilateur pour le langage Rust, mais nous nous en rapprochons.
Sources : Ronja Koistinen, LWN
Et vous ?
Quel est votre avis sur le sujet ?Voir aussi :
GCC se dote d'un nouveau frontend pour le langage de programmation Rust, une version préliminaire de ce compilateur appelé "gccrs" devrait être incluse dans GCC 13 Rust dans le noyau Linux: un projet prometteur, mais pas sans complications. La communauté dresse un bilan lors de l'édition 2023 du Kernel Maintainers Summit La première version officielle de GCC 13 est sur le point d'être publiée, mais n'inclura pas gccrs, le frontend pour le langage Rust. Le compilateur gccrs ne serait pas prêt pour du "vrai" code Rust