RÉFÉRENCE VITTE / Implémentation
État du support
Une forme présente dans l’EBNF n’est pas automatiquement acceptée par chaque frontend ni compilable. Cette matrice lie chaque affirmation aux tests et chemins réellement présents dans le dépôt.
Niveau de garantieÉtat audité sur le dépôt local ; le sous-ensemble natif et le chemin bootstrap/compatibilité sont indiqués séparément.
Source de référence :
grammar/vitte.ebnf · src/tests · src/bootstrap/cli/pipeline.c·État relevé le 27 octobre 2026Le dépôt possède plusieurs chemins de compilation
Le CLI envoie un sous-ensemble vers le frontend natif (HIR, IR, C17) et conserve un chemin bootstrap/compatibilité pour d’autres formes. « Compilé » signifie ici qu’un test du dépôt produit un exécutable et le lance ; une sortie C seule ne prouve pas l’exécution. Les résultats ci-dessous décrivent le commit audité, pas une garantie pour toutes les cibles.
Comment lire la matrice
- EBNF : la construction est écrite dans
grammar/vitte.ebnf. « Non » signale une extension utilisée ailleurs dans le dépôt. - Analyseur : le niveau nomme le parseur ou la commande couverte par une fixture.
checkinclut le parsing, puis continue vers la sémantique. - Compilation :
HIR/IR + C17 + exécutionest une preuve du backend natif ;compatibilité + exécutionpasse par le chemin bootstrap. « Non prouvé » veut dire qu’aucun test ciblé consulté n’établit ce niveau.
Déclarations et types
| Construction | Décrite par l’EBNF | Acceptée par l’analyseur | Réellement compilée dans les tests |
|---|---|---|---|
space et use | Oui | Oui : imports simples/qualifiés et groupes sont passés à check ; le test d’import glob confirme la résolution et le rejet d’un nom privé. | Oui : llvm_imports_runtime.vit compile et s’exécute avec un module importé. |
| Imports qualifiés ambigus | La syntaxe d’import est décrite. | Non confirmé : test-sema marque explicitement import_collision/modules_main.vit comme non résolu. | Non prouvé ; des collisions de noms restent une limite de résolution. |
export et constantes de module | Oui pour les déclarations et exports listés. | Oui dans les fixtures d’imports/export et le test de parité ; les alias d’export forcent le chemin compatibilité. | Oui pour les exports/imports exercés par les fixtures runtime ; pas de preuve pour chaque forme d’alias. |
const, static, alias type, opaque | Oui | const est couvert indirectement par les imports ; pas de fixture ciblée trouvée pour static, alias type ou opaque. | Pas de preuve pour chaque construction ; ne pas extrapoler depuis const vers les autres. |
form non générique, champs imbriqués et tableaux fixes | Oui | Oui : fixtures de grammaire, parité et frontend natif. | Oui : IR natif, émission C17 et exécution pour champs scalaires, tableaux fixes et structures imbriquées. |
form<T> générique | Oui | La syntaxe atteint le chemin de génération dans le cas négatif dédié. | Non pour le backend testé : Box<T> reçoit VITTE_BACKEND_E_CODEGEN. |
pick simple et avec charge utile | Oui pour la déclaration et les types des variantes. | Oui : fixtures de grammaire, parité et frontend natif. | Oui dans le frontend natif : construction, comparaison, motifs de variantes et charges utiles passent IR, C17 et exécution. |
proc et procédures externes extern | Oui | proc est largement exercé ; pas de preuve ciblée relevée pour extern. | proc est compilé dans les tests ; extern n’est pas confirmé de bout en bout. |
requires / ensures | Oui | Oui : test sémantique et fixture de parité. | Oui : contracts_ok.vit est compilé et exécuté par le chemin bootstrap/compatibilité. |
trait, impl, génériques et clauses where | Oui | Le README du parseur bootstrap documente plusieurs de ces formes ; leur couverture n’est pas validée par une fixture runtime représentative. | Non prouvé pour le backend natif ou l’exécution. La documentation de core signale des limites de liaison des traits et génériques. |
intrinsic, macro, déclaration test | Oui | Le parseur bootstrap les décrit ; le test frontend ne confirme que l’acceptation d’une déclaration test par l’émetteur de compatibilité. | Non prouvé à l’exécution. Pour test, seul l’émetteur C de compatibilité est vérifié. |
attributs, modificateurs async, unsafe, comptime | Les modificateurs sont listés ; les attributs ne le sont pas. | Le README du parseur documente les attributs ; la parité vérifie un attribut de procédure. | Pas de preuve de génération/exécution pour cet ensemble. |
| Références et tableaux fixes comme types | Oui | Oui : fixture de grammaire pour les marqueurs de référence ; tableaux dans les fixtures natives. | Oui pour tableaux, indexation et références à des formes dans aggregate_runtime.vit ; cela ne couvre pas toutes les opérations de pointeur. |
Pointeurs, type nullable ?T | Pointeurs oui ; ?T non dans la production EBNF type. | ?T est employé par core, mais son acceptation uniforme n’est pas démontrée par les fixtures sélectionnées. | Non prouvé par la matrice runtime auditée. |
Expressions et instructions
| Construction | Décrite par l’EBNF | Acceptée par l’analyseur | Réellement compilée dans les tests |
|---|---|---|---|
| Arithmétique, logique, comparaisons, affectations composées | Oui | Oui : cas natifs positifs et négatifs, plus parité sémantique. | Oui : frontend natif, IR, C17 et exécution pour le cas arithmétique/logique. |
Cast as Type | Non, absent de l’EBNF actuelle. | Oui dans le test natif des tableaux (as u8). | Oui : ce test natif compile et s’exécute avec des conversions vers u8. |
| Accès de champ, indexation et écriture dans un tableau | Oui | Oui : cas natifs positifs et vérification des erreurs de taille/type. | Oui : IR, C17 et exécution pour champs imbriqués, tableaux fixes et matrices. |
if, while, break, continue | Oui | Oui dans les tests runtime et la suite d’analyse sémantique. | Oui : les fixtures runtime couvrent conditions, boucles while et cibles de boucle. |
for nom in plage | Oui | La syntaxe est décrite ; aucune fixture runtime ciblée dans les 11 exécutables. | Non prouvé dans l’audit runtime. |
for nom in tableau | La forme générale for nom in expression est décrite. | La compilation atteint le diagnostic backend du cas de tableau. | Rejeté dans le test ciblé : la génération C se termine par VITTE_BACKEND_E_CODEGEN. |
match, gardes, else et motifs de charge utile | match et les bras simples sont décrits ; gardes et motifs ne sont pas exprimés par cette production EBNF. | Oui : le frontend natif accepte les gardes, variantes qualifiées, charges utiles et motif joker utilisés par les fixtures. | Oui : IR natif, C17 et exécution pour variantes simples et avec charge utile. |
defer, assert, unsafe, asm | Oui | Décrits par l’EBNF, mais pas tous couverts par les fixtures sélectionnées. | Non prouvé pour chacun dans les tests runtime consultés. |
Coalescence ??, suffixe ?, await, move | Oui pour les formes écrites dans l’EBNF. | Pas de fixture de parité ou runtime représentative identifiée pour chaque opérateur. | Non prouvé au backend/exécution dans cet audit. |
Commandes et preuves exécutées
Les commandes suivantes ont été lancées sur le dépôt local le 27 octobre 2026 :
make test-grammar test-sema test-native-frontend-subset test-native-bootstrap-parity test-runtime: synchronisation EBNF/tokens réussie, 5 fixtures de grammaire, cas sémantiques réussis, 9 cas natifs valides et 18 invalides, 7 cas de parité parseur/AST, 4 cas de parité sémantique et 11 programmes runtime réussis.- Le test natif vérifie explicitement les sorties IR et C17 pour tableaux, formes et variantes
pickavec charge utile. Il vérifie aussi le rejet backend d’une forme générique et d’une boucleforsur tableau.
La vérification check-ebnf-frontend-sync porte sur les mots-clés, les opérateurs et la couverture des tokens ; elle ne prouve pas que chaque production EBNF est supportée par chaque backend.