gcc arrive très bien à conserver les commentaires C (et même, ajouter les lignes du fichier C en commentaire) dans les fichiers assembleur qu'il génère. D'ailleurs, c'est indispensable qu'il sache faire ça car c'est aussi utilisé pour générer les informations de debug, qui permettent à un debugger de savoir quelle ligne du fichier C est en train de s'exécuter.
Encore plus fort: quand on génère du C, on peut ajouter des directives #line et #file, et du coup, annoter que le fichier est généré à partir d'un autre. Et cela sera aussi intégré et le debugger pourra afficher où on est dans le fichier source qui a servi à la génération.
Si Grumpy (et les autres transpileurs ) ne sait pas faire ça, alors comment on fait pour debugger? Obligé de regarder le code généré qui n'a pas de commentaires, et retrouver l'équivalent dans le fichier Python à la main? ça me semble être la moindre des choses, quand même?
[^] # Re: logique pour Google
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 10.
gcc arrive très bien à conserver les commentaires C (et même, ajouter les lignes du fichier C en commentaire) dans les fichiers assembleur qu'il génère. D'ailleurs, c'est indispensable qu'il sache faire ça car c'est aussi utilisé pour générer les informations de debug, qui permettent à un debugger de savoir quelle ligne du fichier C est en train de s'exécuter.
Encore plus fort: quand on génère du C, on peut ajouter des directives #line et #file, et du coup, annoter que le fichier est généré à partir d'un autre. Et cela sera aussi intégré et le debugger pourra afficher où on est dans le fichier source qui a servi à la génération.
Si Grumpy (et les autres transpileurs ) ne sait pas faire ça, alors comment on fait pour debugger? Obligé de regarder le code généré qui n'a pas de commentaires, et retrouver l'équivalent dans le fichier Python à la main? ça me semble être la moindre des choses, quand même?