ne crains-tu pas qu'au niveau des messages on se retrouve un peu loin des paradigmes du langage initial ?
Je prévois une compilation en plusieurs phases :
Phase 0: l'analyse lexicale transforme le texte en "Token Stream"
Phase 1: l'analyse syntaxique transforme le "Token Stream" en un AST annoté de metadata (nom du fichier, ligne, colonne, token, ...)
Phase 2: l'analyse sémantique parcours ce premier AST pour vérifier le respect des règles du langage
Phase 3: l'analyse statique parcours à nouveau l'AST pour vérifier la cohérence des types du mieux qu'il peut, ainsi que l'inférence de type quand c'est possible
Phase 4: le compilateur traduit l'AST annoté par les 2 phases précédentes en langage Rust
Phase 5: appel du compilateur Rust
Mon hypothèse, c'est qu'une fois arrivée à l'etape 4, on a la garantie que le code Rust produit ne générera pas d'erreur de compilation.
Les éléments qui me permettent de soutenir cette hypothèse sont :
l'AST consommé par l'étape 4 est censé avoir toutes les informations nécessaire pour produire un code complet
le code produit par les différents noeuds de l'AST a été testé en amont (un Literal::Number va toujours produire le même code)
l'AST garanti qu'on ne trouvera pas un "bloc de fonction" utilisé comme string literal pour un import, donc le code Rust produit reflète cet aspect aussi, on ne peut trouver que du code Rust valide dans le contexte/scope ou il est produit car c'est comme ça que l'implémentation aura été faite
En fait, c'est comme se demander : que se passe-t-il si après avoir compilé le C en ASM, l'assembleur renvoi une erreur ? Le soucis est au niveau de GCC ici, pas au niveau du code que je lui fournit.
Maintenant, que mon hypothèse est posée, l'implémentation suivi par les tests la confirmera ou l'infirmera.
A ce moment là, je peux toujours identifier grâce au message d'erreur de rustc quel est le bout de code qui produit l'erreur, et grâce aux annotations de l'AST produites en phase 0 à 3, retrouver le code Letlang concerné.
NB: Dans ce journal, j'explique comment j'ai commencé l'implémentation de la phase 4 et 5, en construisant à la main l'AST "valide".
J'ai fait il y a quelques temps une grammaire pest pour la phase 0 et 1. Mais comme je change d'avis sur la syntaxe comme je change de chemise, c'était contre productif.
Par contre, l'AST lui risque pas de bouger beaucoup, après tout, les concepts sont la, et les informations dont j'ai besoin pour les représenter aussi. Au final, commencer par la phase 4 et 5 c'est plus simple, et ça me fournit une suite de test pour implémenter les phases précédentes.
[^] # Re: j'en dis que
Posté par David Delassus (site web personnel) . En réponse au journal [Letlang] Écrire un compilateur en Rust. Évalué à 2.
Je prévois une compilation en plusieurs phases :
Mon hypothèse, c'est qu'une fois arrivée à l'etape 4, on a la garantie que le code Rust produit ne générera pas d'erreur de compilation.
Les éléments qui me permettent de soutenir cette hypothèse sont :
En fait, c'est comme se demander : que se passe-t-il si après avoir compilé le C en ASM, l'assembleur renvoi une erreur ? Le soucis est au niveau de GCC ici, pas au niveau du code que je lui fournit.
Maintenant, que mon hypothèse est posée, l'implémentation suivi par les tests la confirmera ou l'infirmera.
A ce moment là, je peux toujours identifier grâce au message d'erreur de
rustcquel est le bout de code qui produit l'erreur, et grâce aux annotations de l'AST produites en phase 0 à 3, retrouver le code Letlang concerné.NB: Dans ce journal, j'explique comment j'ai commencé l'implémentation de la phase 4 et 5, en construisant à la main l'AST "valide".
J'ai fait il y a quelques temps une grammaire pest pour la phase 0 et 1. Mais comme je change d'avis sur la syntaxe comme je change de chemise, c'était contre productif.
Par contre, l'AST lui risque pas de bouger beaucoup, après tout, les concepts sont la, et les informations dont j'ai besoin pour les représenter aussi. Au final, commencer par la phase 4 et 5 c'est plus simple, et ça me fournit une suite de test pour implémenter les phases précédentes.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg