Avancées du développement du compilateur Rust basé sur GCC

État d’avancement du compilateur Rust basé sur GCC

• gccrs, le projet de compilateur Rust basé sur GCC, a été lancé en 2014 avec pour objectif d’implémenter un compilateur Rust au sein de la GNU Compiler Collection (GCC).
• L’objectif de gccrs était d’être inclus dans la sortie de GCC 13, mais cela n’a pas été atteint, et le projet vise désormais une intégration dans GCC 14, dont la sortie est attendue à la mi-2024.
• gccrs cible Rust version 1.49, soit la dernière version avant l’introduction des const generics.
• L’un des principes importants du projet gccrs est de ne pas créer un « superset » de Rust, mais de reproduire fidèlement la sortie de rustc.
• La bibliothèque standard de Rust est composée de plusieurs « crates », et gccrs se concentre sur la prise en charge de la compilation des crates core et alloc.
• gccrs ne peut actuellement pas compiler ces crates en raison de plusieurs fonctionnalités manquantes, notamment l’absence de borrow checker et le manque d’LLVM intrinsics non pris en charge par GCC.

Tirer parti des avantages de l’écosystème GCC

• L’une des principales raisons du développement de gccrs est de permettre l’utilisation des plugins de sécurité de GCC.
• gccrs est déjà utilisé par la communauté homebrew de la Sega Dreamcast, et permet d’effectuer une analyse statique de code Rust unsafe à l’aide de plugins GCC.
• Les travaux sur gccrs ont aussi permis de contribuer à des fonctionnalités supplémentaires dans la spécification de Rust, avec la volonté de participer à la rédaction de la spécification officielle du langage.

Fonctionnalités en cours de développement

• gccrs manque encore de nombreuses fonctionnalités clés, dont async/await, des LLVM intrinsics absents de GCC, ainsi que la macro format_args!().
• Le projet Polonius implémente un borrow checker qui calcule la durée de vie des références avec un algorithme différent afin de corriger les limites du borrow checker actuel de rustc.
• Le travail sur la macro format_args!() a commencé ; elle est nécessaire pour construire les arguments transmis aux autres macros de formatage de chaînes.

rustc_codegen_gcc

• rustc_codegen_gcc est un autre projet Rust basé sur GCC, plus mature que gccrs et à la portée plus limitée.
• rustc_codegen_gcc utilise la bibliothèque libgccjit pour se connecter à l’API du backend LLVM de rustc, et effectue la compilation à un stade tardif de rustc et de GCC.
• En octobre 2023, rustc_codegen_gcc pouvait compiler Rust for Linux sans patch supplémentaire.

Rust for Linux

• Le projet Rust for Linux fournit de la documentation sur la manière de construire du code Rust pour le noyau avec rustc ou rustc_codegen_gcc.
• gccrs vise la prise en charge de Rust for Linux, mais cela semble encore lointain en raison de l’écart important avec la version de rustc actuellement prise en charge.

L’avis de GN⁺

• Le projet gccrs vise à implémenter un compilateur Rust basé sur GCC, ce qui apporte de la diversité à l’écosystème Rust et offre le potentiel de réutiliser des outils existants comme les plugins de sécurité de GCC.
• Bien que gccrs ne puisse pas encore compiler les parties essentielles de la bibliothèque standard de Rust, il est notable qu’il ait déjà trouvé un cas d’usage réel dans la communauté homebrew de la Sega Dreamcast.
• Cet article offre un aperçu intéressant des différentes implémentations de compilateurs du langage Rust et des possibilités d’extension de son écosystème.

[GN⁺]

Avis sur Hacker News

• Résumé du premier commentaire :

  • L’article semble peu convaincant sur ses arguments concernant la motivation du développement de gccrs.
  • gccrs est en cours de développement afin de tirer parti des plugins de sécurité de GCC.
  • L’initiative « Rust for Linux », qui ajoute la prise en charge de Rust au noyau Linux, constitue une autre raison.
  • C’est une motivation importante, car de nombreux développeurs du noyau veulent pouvoir compiler le noyau Linux uniquement avec la toolchain GNU.
  • La raison d’utiliser GCC comme backend est expliquée, mais l’explication manque sur la nécessité d’un frontend dupliqué.
  • Il faut tirer les leçons des erreurs du C++, et la multiplication des frontends complique le développement multi-plateforme.
  • Une attention particulière est portée au fait que gccrs ne devienne pas « GNU Rust », et il cherche à reproduire la sortie de rustc.

• Résumé du deuxième commentaire :

  • Rust a besoin d’un standard du langage.
  • De nombreuses organisations et industries n’adopteront pas Rust en l’absence de standard.
  • D’autres langages comme C, C++, C#, JavaScript (ECMAScript) disposent tous d’un standard.

• Résumé du troisième commentaire :

  • La réaction négative envers GCC-RS est surprenante.
  • Si un langage ne possède pas plusieurs implémentations, alors il est incomplet.

• Résumé du quatrième commentaire :

  • gccrs permettra la prise en charge de Rust sur des architectures non prises en charge par LLVM.

• Résumé du cinquième commentaire :

  • Chercher à reproduire avec gccrs jusqu’aux bugs et bizarreries de rustc est une erreur.
  • Rust ne dispose pas de spécification officielle, et s’appuyer sur une unique implémentation de référence comme documentation est une faiblesse à long terme.
  • Vouloir que le code existant fonctionne sur toutes les implémentations est raisonnable, mais cela pose le problème de pérenniser de mauvaises décisions et des bugs.
  • Microsoft fait beaucoup d’efforts pour que les anciens programmes continuent de fonctionner.
  • Rust ne devrait pas s’imposer ce fardeau si tôt dans le développement du langage.
  • Pour qu’un langage évolue, il doit accepter la QA et le QC.
  • Les langages dotés de standards solides acceptent cette idée.

• Résumé du sixième commentaire :

  • Merci d’avoir posté le lien vers lwn.net, cela a rappelé de renouveler l’abonnement.

• Résumé du septième commentaire :

  • Linux peut déjà être compilé avec clang.
  • Développer et maintenir cet effort redondant au nom de la « pureté » GNU ne semble pas en valoir la peine.