La première version officielle de GCC 13 est sur le point de sortir, et vous serez peut-être surpris d'apprendre que gccrs ne sera pas inclus dans cette version. Le but de ce billet est d'expliquer un peu plus en détail pourquoi cela a été fait et comment vous pouvez encore essayer notre compilateur si vous le souhaitez.
En 2022, nous avons commencé à étudier le processus de fusion de notre code en amont avec GCC. Rapidement, notre frontend a été accepté pour la fusion, ce qui a été un grand moment pour nous - cela a démontré la foi des gens dans la communauté gccrs et dans l'objectif du projet d'avoir une implémentation alternative de la chaîne d'outils GCC pour le langage de programmation Rust. Étant donné que le compilateur n'est pas encore prêt, nous avons décidé de suivre ce processus avec certaines limitations.
Nous espérions qu'en montrant clairement que le compilateur n'était pas encore prêt pour du vrai code Rust, nous pourrions obtenir des retours précieux de la part des premiers utilisateurs ainsi qu'un plus grand engagement de la part de deux communautés différentes - celle de Rust et celle de GCC. Nous avons continué à travailler aussi dur que possible jusqu'à la date limite de publication pour faire fonctionner autant de choses que possible, mais maintenant que la version 13.1 de GCC est arrivée, nous ne sommes toujours pas au point en termes de complétude.
Cela signifie qu'en utilisant gccrs, vous n'êtes toujours pas en mesure de faire les "choses faciles de Rust" - des exemples comme "Hello World !", ou l'utilisation de la bibliothèque standard en général, ne fonctionneront pas. De même, des concepts plus complexes qui sont essentiels au langage de programmation Rust, comme la vérification des emprunts, ne sont pas encore implémentés, et gccrs ne sera pas considéré comme complet sans ces fonctionnalités. Nous pensons que cela causerait beaucoup de confusion pour les utilisateurs peu méfiants, qui pourraient voir gccrs comme faisant partie d'une version officielle de GCC et s'attendre à un compilateur fonctionnel.
Pourquoi ne sommes-nous pas "prêts" ?
Dire que Rust n'est pas un langage facile à implémenter serait un euphémisme. Et même si nous pensons que le fait que Rust soit si strict est l'une des grandes forces du langage, car il limite le potentiel d'erreurs de l'utilisateur, annule la possibilité d'un comportement non défini dans un code idiomatique, et protège l'utilisateur et l'environnement contre de nombreuses vulnérabilités trouvées dans les programmes C et C++, cela a un coût - Rust est conçu de telle manière que rien ne fonctionnera, à moins que tout ne fonctionne.
Mais qu'est-ce que cela signifie ?
La bibliothèque standard de Rust
La bibliothèque standard peut être vue comme un ensemble de crates dépendant les uns des autres, dont les deux composants principaux sont
core et
alloc. Le crate
alloc fournit des abstractions autour des allocations dynamiques de mémoire en Rust, comme le type
String ou
Vec. Le crate
core, quant à lui, fournit des fonctionnalités qui sont beaucoup plus intrinsèques au langage et qui ne nécessitent pas de mémoire dynamique - cela va de types cruciaux comme
Option et
Result, à des fonctionnalités moins connues comme la création de slices, ou l'implémentation d'opérations numériques pour les types de nombres primitifs en utilisant les traits
Add,
Sub,
Mul et
Div.
Le crate
core déclare également des abstractions qui sont implémentées directement dans le compilateur Rust : les intrinsèques du compilateur, les macros intégrées, les éléments lang... et il y a une abondance de ces abstractions !
En l'état actuel, gccrs ne peut pas encore compiler la version du crate
core que nous visons : par exemple, nous ne sommes toujours pas en mesure de compiler les boucles
for, qui dépendent d'une certaine désucrage pour le pattern matching, ainsi que les itérateurs, un élément lang très complexe et un trait, tous définis dans libcore.
De plus, bien que nous voulions cibler la version Rust 1.49 de la bibliothèque de base, nous devons également implémenter des fonctionnalités qui n'ont été stabilisées que dans les versions ultérieures de Rust, ou qui peuvent encore être instables à ce jour, car la bibliothèque standard de Rust est un ensemble de crates qui utilisent de nouvelles fonctionnalités et les testent.
Ce qui est astucieux, c'est qu'en compilant le crate
core sans aucune modification, nous évitons d'introduire des incohérences dans l'implémentation, puisqu'il implémente le comportement du langage de
core. Pour compliquer les choses, Rust 1.49 n'a pas vraiment de suite de tests
#![no_core], donc trouver le bon comportement nécessite beaucoup d'investigations de notre part.
Un autre extrait de code que l'on peut s'attendre à voir géré par gccrs est le suivant :
1
2
3
| fn main() {
println!("Hello, world!");
} |
mais ce n'est pas le cas pour l'instant ! Si vous connaissez un peu Rust, vous savez que
println! est une invocation de macro. Les macros sont compliquées, mais aussi extrêmement puissantes. Nous avons travaillé sur elles pendant un certain temps maintenant, et certaines des fonctionnalités les plus complexes ne sont toujours pas correctement implémentées.
Si vous avez déjà utilisé
println, vous savez qu'il permet d'obtenir des chaînes de format très puissantes :
1
2
3
4
| println!("Hello {name}");
println!("Debugging {something:?} and {:#?}", this_as_well);
println!("printing numbers: {:04}, {:#x}", leading_zeros, hexa_value)
println!("printing dashes ! {:-<5}", "some string"); |
La gestion de ces chaînes de format est effectuée par le compilateur, à l'aide des macros intégrées
format_args! et
format_args_nl!. Ces macros sont extrêmement complexes, tout comme les spécificateurs de format qu'elles offrent aux utilisateurs. Une fois que ces spécificateurs sont correctement analysés, nous devons penser à créer des appels aux fonctions fmt correspondantes de
Debug,
Display ou d'autres traits de formatage. La sortie résultant de ces appels doit alors être intercalée dans la chaîne de format d'origine, en supprimant les crochets ou d'autres parties des spécificateurs.
Bien que tout cela semble assez facile à comprendre et à utiliser, le compilateur Rust doit faire beaucoup de travail pour gérer ces invocations de macros !
Par ailleurs, nous avons récemment commencé à travailler sur les macros procédurales. Certaines macros procédurales intégrées sont nécessaires pour construire le crate
core, comme les macros derive intégrées (
#[derive(Clone, Copy)]) qui sont assez familières aux programmeurs Rust. Vous verrez aussi souvent du code Rust utiliser
#[derive(Debug)], ce qui est lié à notre travail à venir sur les chaînes de format mentionnées ci-dessus.
Où en sommes-nous ?
Bien que tout cela semble représenter beaucoup de travail, nous sommes confiants dans nos progrès et nous espérons nous rapprocher de plus en plus du fonctionnement du crate
core dans les prochains mois. Il reste également beaucoup de travail important pour produire un compilateur Rust valide, c'est pourquoi nous allons passer les prochains mois à nous concentrer sur le crate
core ainsi que sur l'implémentation d'un borrow-checker, et sur le développement de l'outillage nécessaire pour nous permettre d'essayer de passer la suite de tests Rust 1.49.
Notre objectif est de distribuer la version Rust 1.49 de la bibliothèque standard avec notre compilateur dans la prochaine version majeure de GCC, GCC 14, et nous espérons rétroporter suffisamment de changements sur la branche GCC 13 pour que le crate
core fonctionne à temps pour la version GCC 13.2. Cela permettra aux utilisateurs de commencer facilement à expérimenter avec le compilateur pour les programmes Rust
#![no_std] et, espérons-le, quelques cibles embarquées.
En attendant, si vous souhaitez toujours essayer le compilateur et nous aider à résoudre les problèmes, il y a plusieurs possibilités :
- Vous pouvez compiler GCC à partir des sources, soit à partir de notre dépôt GitHub, soit à partir du dépôt GCC en amont.
- Utiliser Compiler Explorer
- Utiliser notre image Docker. Ce conteneur est livré avec une version de gccrs ainsi que cargo-gccrs.
- Enfin, nous prévoyons également de produire des versions binaires régulières très prochainement - cela vous permettra d'installer une version fonctionnelle, mais instable, de gccrs, et de l'utiliser avec cargo-gccrs ou seul. Ces binaires seront disponibles sur le site web d'Embecosm sous peu, à peu près au moment de la sortie de GCC 13.1.
Aller de l'avant
Bien que nous n'ayons pas atteint la ligne d'arrivée pour la première version de GCC 13, nous sommes satisfaits des progrès réalisés jusqu'à présent et nous nous réjouissons de l'avenir.
Nous avons déjà achevé la fusion initiale avec GCC upstream, ce qui a pris beaucoup de temps et n'aura pas besoin d'être répété. Cela nous permettra de nous concentrer encore plus sur le développement du compilateur pour GCC 14, et nous permettra de pousser facilement des correctifs en amont. Ce temps sera utilisé pour produire un compilateur de meilleure qualité, et pour espérer se rapprocher d'un véritable compilateur Rust. Cela a également augmenté la visibilité du projet, avec de nombreux articles écrits sur nos différentes avancées.
Nous continuerons à travailler dur pour produire un compilateur Rust de qualité pour GCC, et nous nous en tiendrons à nos principes existants : nous voulons respecter le langage de programmation Rust, et ne pas lui nuire de quelque manière que ce soit. Le but de gccrs n'est pas de contourner les différents processus entourant le langage Rust, ni d'offrir une échappatoire à ce qui devrait être du code Rust invalide. Nous utilisons rustc comme un guide, et continuerons à traiter chaque différence entre les deux compilateurs comme un bug.
À très bientôt !
GCC 13 se dote de nouvelles fonctionnalités dans la partie frontale du langage C pour le rapprocher du C++
Quel est votre avis sur le sujet ?
Répondre avec citation
Envoyé par selmanjo
Partager