Les parsingurs GCC et Clang sont-ils vraiment manuscrits?

Il semble que GCC et LLVM-Clang utilisent des parsingurs de descente récursifs manuscrits , et non pas des parsings ascendantes de type Bison-Flex, générées par ordinateur.

Quelqu’un pourrait-il s’il vous plaît confirmer que c’est le cas? Et si oui, pourquoi les frameworks de compilateur grand public utilisent-ils des parsingurs manuscrits?

Mise à jour : blog intéressant sur ce sujet ici

Oui:

  • GCC a utilisé un parsingur yacc (bison) une fois, mais il a été remplacé par un parsingur récursif écrit à la main à un moment donné dans la série 3.x: voir http://gcc.gnu.org/wiki/New_C_Parser pour des liens vers les correctifs pertinents.

  • Clang utilise également un parsingur de descente récursif écrit à la main: voir la section “Un parsingur unifié pour C, Objective C, C ++ et Objective C ++” à la fin de http://clang.llvm.org/features.html .

Il y a un théorème folklorique qui dit que C est difficile à parsingr et C ++ essentiellement impossible.

Ce n’est pas vrai

Ce qui est vrai, c’est que C et C ++ sont assez difficiles à parsingr en utilisant les parsingurs LALR (1) sans piratage de la machine d’parsing et enchevêtrement dans les données de la table des symboles. En fait, GCC avait l’habitude de les parsingr, en utilisant YACC et du piratage supplémentaire comme celui-ci, et oui, c’était moche. Maintenant, GCC utilise des parsingurs manuscrits, mais toujours avec le piratage de la table des symboles. Les gens de Clang n’ont jamais essayé d’utiliser des générateurs d’parsingurs automatisés; AFAIK l’parsingur de Clang a toujours été recursive codée à la main.

Ce qui est vrai, c’est que C et C ++ sont relativement faciles à parsingr avec des parsingurs générés automatiquement plus puissants, tels que les parsingurs GLR , et vous n’avez pas besoin de hacks. L’parsingur Elsa C ++ en est un exemple. Notre Front End C ++ en est un autre (comme tous nos produits frontaux de “compilateur”, GLR est une technologie d’parsing syntaxique très intéressante).

Notre frontal C ++ n’est pas aussi rapide que celui de GCC, et certainement plus lent qu’Elsa; nous avons mis peu d’efforts pour le régler avec précaution car nous avons d’autres problèmes plus urgents (néanmoins, il a été utilisé sur des millions de lignes de code C ++). Elsa est probablement plus lente que GCC simplement parce que c’est plus général. Compte tenu de la vitesse des processeurs ces jours-ci, ces différences peuvent ne pas avoir beaucoup d’importance dans la pratique.

Mais les “vrais compilateurs”, largement diffusés aujourd’hui, ont leurs racines dans les compilateurs d’il y a 10 ou 20 ans ou plus. Les inefficiences importaient alors beaucoup plus, et personne n’avait entendu parler des parsingurs syntaxiques de la RGL, alors les gens ont fait ce qu’ils savaient faire. Clang est certainement plus récent, mais les théorèmes folkloriques conservent longtemps leur «pouvoir de persuasion».

Vous n’avez plus à le faire comme ça. Vous pouvez très raisonnablement utiliser GLR et d’autres parsingurs tels que des frontaux, avec une amélioration de la maintenabilité du compilateur.

Ce qui est vrai, c’est qu’avoir une grammaire qui correspond au comportement de votre compilateur est difficile. Alors que pratiquement tous les compilateurs C ++ implémentent (la plupart) du standard d’origine, ils ont également beaucoup d’extensions de coin sombre, par exemple des spécifications DLL dans les compilateurs MS, etc. Si vous avez un moteur d’parsing puissant, vous pouvez essayer la grammaire finale pour correspondre à la réalité, plutôt que d’essayer de plier votre grammaire pour correspondre aux limitations de votre générateur d’parsingurs.

EDIT November 2012: Depuis l’écriture de cette réponse, nous avons amélioré notre interface C ++ pour gérer le C ++ 11 complet, y compris les dialectes ANSI, GNU et MS. Bien qu’il y ait beaucoup de choses supplémentaires, nous n’avons pas besoin de changer notre moteur d’parsing; nous venons de réviser les règles de grammaire. Nous avons dû modifier l’parsing sémantique. C ++ 11 est très compliqué du sharepoint vue sémantique, et ce travail submerge les efforts d’exécution de l’parsingur.

EDIT février 2015: … gère maintenant C ++ 14 complet. (Voir get AST lisible par l ‘humain à partir du code c ++ pour une parsing GLR d’ un simple bit de code, et la fameuse «parsing la plus vexante» de C ++).

EDIT avril 2017: gère maintenant (brouillon) C ++ 17.