Validated Code Translation for Projects with External Libraries

1. Problématique

La traduction de code assistée par les Grands Modèles de Langage (LLM) pour la migration de systèmes vers des langages sûrs comme Rust a fait des progrès significatifs. Cependant, les approches existantes échouent souvent lorsque les programmes sources dépendent fortement de bibliothèques externes. Deux limitations majeures sont identifiées :

1. Hallucinations et résolution d'API : Les LLM ont tendance à inventer des bibliothèques ou des API inexistantes dans la langue cible (Rust). De plus, même lorsqu'ils identifient la bonne API, ils échouent souvent à générer les importations nécessaires pour rendre l'appel compilable. En Rust, la visibilité des méthodes dépend souvent de traits spécifiques ou de ré-exportations complexes, rendant la résolution d'importation non triviale et non locale.
2. Validation sémantique avec types opaques : Valider l'équivalence sémantique entre une fonction source (Go) et sa traduction (Rust) est extrêmement difficile lorsque les types d'entrée/sortie sont définis par des bibliothèques externes. Ces types sont souvent opaques (champs privés, invariants internes) et ne peuvent pas être manipulés par une conversion structurelle directe (champ par champ). Les méthodes de validation traditionnelles, qui supposent des types structurellement identiques ou un accès direct aux champs, échouent dans ce contexte.

2. Méthodologie

Les auteurs proposent un cadre de traduction et de validation nommé CrossCrate, conçu spécifiquement pour traduire des projets Go vers Rust en présence de dépendances externes. L'approche se déroule en trois étapes principales :

A. Cartographie des bibliothèques et résolution d'import (RAG)

Pour résoudre le problème des hallucinations et des imports manquants, l'approche utilise une architecture RAG (Retrieval-Augmented Generation) :

• Base de connaissances par Crate : Pour chaque bibliothèque Rust cible, une base de connaissances est pré-calculée. Elle contient non seulement les signatures des API publiques, mais aussi les chemins d'importation valides (y compris les ré-exportations et les traits nécessaires).
• Recherche sémantique : Lors de la traduction d'une fonction Go, le système extrait les API appelées, recherche les équivalents Rust les plus pertinents dans la base de connaissances, et injecte dans le prompt du LLM les candidats de code avec leurs imports explicites. Cela garantit que le code généré est non seulement correct sémantiquement, mais aussi compilable.

B. Génération de la traduction

Le LLM traduit chaque fonction et type de manière modulaire, guidé par un résumé des dépendances et les suggestions d'API enrichies par le RAG. Le système traite les types définis par l'utilisateur et les types de bibliothèque de manière distincte.

C. Validation par Interopérabilité et Tests Différentiels

C'est la contribution la plus innovante pour gérer les types opaques. Au lieu de comparer directement les valeurs Go et Rust (impossible à cause de la représentation mémoire différente), le système introduit une représentation intermédiaire neutre :

1. Schéma Protobuf (IDF) : Un LLM synthétise un schéma Protobuf (TProto) qui sert de "conteneur" universel. Ce schéma est généré à partir des types Go sources.
2. Génération de "Glue Code" (Adaptateurs) : Le système synthétise des adaptateurs bidirectionnels :
   • Go -> TProto : Sérialise les types Go (y compris les types opaques de bibliothèque) en utilisant uniquement les API publiques de la bibliothèque (ex: méthodes de sérialisation, constructeurs).
   • TProto -> Rust : Désérialise le conteneur vers le type Rust cible en utilisant les API publiques Rust.
3. Validation en Boucle (Round-trip) : Avant de tester l'équivalence, le système vérifie que la conversion Go -> TProto -> Go est fidèle (reconstruction parfaite des valeurs d'origine). Cela valide que le schéma Protobuf capture toute l'information sémantique nécessaire.
4. Tests Différentiels I/O : Une fois l'interopérabilité établie, le système exécute les tests unitaires Go, convertit les entrées vers Rust via l'adaptateur, exécute la fonction Rust, puis convertit le résultat Rust vers Go. Si les résultats correspondent, l'équivalence I/O est validée.

3. Contributions Clés

• Première approche validée pour les dépendances externes : C'est la première méthode capable de traduire et valider des fonctions utilisant des types opaques de bibliothèques externes, là où les méthodes précédentes échouaient.
• RAG pour la résolution d'API Rust : Introduction d'une base de connaissances spécifique aux "crates" Rust incluant les chemins d'importation complexes, réduisant drastiquement les erreurs de compilation dues à des imports manquants.
• Adaptateurs basés sur les API publiques : Une méthode pour contourner l'opacité des types de bibliothèque en synthétisant des convertisseurs qui respectent strictement les invariants des bibliothèques (via des appels d'API) plutôt que d'accéder à la mémoire brute.
• Validation par Protobuf : Utilisation d'un format intermédiaire standardisé pour permettre des tests différentiels entre deux langages aux représentations de valeurs incompatibles.

4. Résultats Expérimentaux

L'évaluation a été menée sur six dépôts Go réels avec des dépendances non triviales (cryptographie, dérivation de clés, parsing de temps), tels que age, pbkdf2, et argon2-hashing.

• Taux de succès global : L'approche atteint un taux de réussite moyen de 95,83 % pour la compilation et l'équivalence I/O.
• Amélioration par rapport à l'état de l'art :
  • Par rapport à l'outil de référence Oxidizer (qui ne gère pas bien les dépendances externes), CrossCrate améliore le taux de réussite d'environ 2x en moyenne.
  • Dans le cas le plus complexe (le dépôt age avec 38 API de bibliothèque distinctes), le taux de réussite passe de 0 % (avec les approches sans RAG) à 80 %.
• Impact des composants (Ablation) :
  • Sans la base de connaissances RAG et la résolution d'import, le taux de compilation chute à environ 41 % (et l'équivalence à 0 %).
  • Cela démontre que la simple génération de code par LLM est insuffisante sans la résolution précise des imports et des API.

5. Signification et Impact

Ce travail résout un goulot d'étranglement majeur dans la migration de code vers Rust : la gestion des écosystèmes de bibliothèques. En prouvant qu'il est possible de valider sémantiquement des traductions manipulant des types opaques, l'article ouvre la voie à une migration automatisée et fiable de systèmes critiques (sécurité, cryptographie) qui reposent massivement sur des bibliothèques tierces.

La méthodologie proposée (RAG pour les imports + Adaptateurs via schéma neutre pour la validation) est potentiellement applicable à d'autres paires de langages modernes, dépassant le cadre spécifique Go-Rust pour offrir une solution générale aux défis de l'interopérabilité et de la traduction de code assistée par IA.