rust-port

L'objectif est le Rust qu'un développeur Rust aurait écrit pour résoudre le même problème, avec le même comportement observable. Une translittération ligne par ligne, du C écrit en syntaxe Rust ou du Python avec Box<dyn Any>, compile mais garde chaque problème de l'original et ajoute le borrow checker par-dessus. Portez le comportement, pas la structure. D'abord, comprenez l'original avant d'écrire quoi que ce soit: lisez le code et ses tests et tout ce qui l'appelle; listez le comportement observable, chaque fonction publique, ses entrées, ses sorties et chaque façon dont elle peut échouer, y compris les parties silencieuses, l'ordre des résultats, la résolution des égalités, l'entrée vide, le traitement des espaces et de la casse, les limites d'entiers, et ce qui compte comme une erreur par opposition à un cas limite valide; notez ce qui est accessoire, les choses que l'original ne fait que parce que c'est son langage, comme la gestion manuelle de la mémoire, les paramètres de sortie, les retours NULL, l'état global, les tampons de taille fixe, une classe qui existe seulement pour regrouper des fonctions, ou les vérifications isinstance; et si l'original a un bogue ou une ambiguïté, gardez son comportement, signalez-le dans les notes de portage, et laissez l'utilisateur décider, puisque un portage n'est pas l'endroit pour corriger silencieusement des choses. Ensuite, portez les tests d'abord. Traduisez les tests d'origine en tests Rust avant de porter l'implémentation, en gardant un test Rust par test d'origine, avec un nom qui y renvoie, pour qu'un lecteur puisse vérifier la couverture. Les tests sont la définition du "même comportement". Si l'original n'a pas de tests, écrivez des tests de caractérisation à partir de la liste de comportements. Troisièmement, concevez l'API Rust à partir de la liste de comportements, pas à partir de la forme de l'original, puis implémentez par rapport aux tests portés, en utilisant les tables de correspondance pour C et C++, Python, et Go, JavaScript et TypeScript du skill. Gardez le portage proportionné: faites-le correspondre sur les entrées qu'il reçoit vraiment, utilisez la bibliothèque standard Rust pour le reste, ne réimplémentez pas le runtime du langage source, ne faites pas grossir l'API au-delà de la surface publique de l'original plus les implémentations de traits standards que les appelants Rust attendent, et gardez l'algorithme sauf s'il est faux, en le disant dans les notes quand il est échangé. Comme contrôle de taille, un portage depuis C ou C++ atterrit généralement près de la taille de l'original, tandis qu'un portage depuis Python ou JavaScript atterrit généralement à deux ou trois fois l'original, parce que les types, les énumérations d'erreur et leurs implémentations de traits sont explicites en Rust. Limites telles qu'écrites dans le SKILL.md: vérifiez avec cargo build, cargo test et cargo clippy avec avertissements refusés si une chaîne d'outils Rust est disponible, et corrigez tout avant de rapporter. Chaque test porté doit passer, et si les tests de l'original peuvent aussi être lancés, lancez-les et comparez les résultats sur les mêmes entrées. À côté du code, rédigez un court PORTING.md avec une table de correspondance d'API, une correspondance de tests, des différences délibérées, des particularités préservées, et une vérification, c'est-à-dire quelles commandes ont été lancées et leur résultat, ou une déclaration simple qu'elles n'ont pas pu être lancées. Les tests différentiels par rapport à l'original valent la peine, mais quelques dizaines d'entrées réalistes et de cas limites répondent à la question, tandis qu'un harnais de fuzzing sur des millions d'entrées trouve généralement juste des divergences exotiques qui appartiennent aux notes.