RÉFÉRENCE VITTE / Index

Référence Vitte

Une documentation de consultation pour retrouver rapidement une syntaxe, un type, une commande ou une limite du compilateur.

Rechercher dans les fiches de référence

/

12 fiches · recherche dans les titres, résumés et contenus

01 Grammaire et lexiqueCommentaires, identifiants, mots-clés et littéraux.OUVRIR LA PAGE → Portée de cette page grammar/vitte.ebnf est le fichier de syntaxe canonique et indique qu’il décrit une syntaxe acceptée par le parseur. Le contrôle automatisé synchronise les mots-clés, opérateurs et tokens ; il ne compare pas chaque production. Les fixtures valident une partie de la grammaire, et les autres frontends peuvent accepter des extensions absentes de l’EBNF. Consulte l’état détaillé du support avant de compter sur une forme. Structure générale Un fichier est une suite de déclarations suivie de la fin du fichier. Les déclarations les plus courantes sont un en-tête de module space , des imports, des constantes, des types et des procédures. space exemple::calcul;const REPONSE: i64 = 42;proc additionner(gauche: i64, droite: i64) -> i64 { return gauche + droite;} Mots-clés La grammaire réserve les mots suivants. Leur apparition comme noms d’identifiants ordinaires est donc limitée : space use export const static type opaque form pick trait impl proc extern intrinsic macro test pub async unsafe comptime where requires ensures let mut set return give break continue defer assert if elif else while loop for in match asm and or not move ref await self true false null Cette liste est dérivée de grammar/vitte.ebnf . L’implémentation peut avoir d’autres mots contextuels ; la table lexicale du compilateur et la grammaire doivent rester alignées. Identifiants et commentaires Un identifiant commence par une lettre, un souligné ou un caractère Unicode non ASCII valide ; les chiffres sont permis après le premier caractère. Les espaces et caractères de contrôle ne font pas partie d’un identifiant. La casse compte : score et Score désignent deux noms différents. Les espaces blancs sont ignorés entre les tokens. Les commentaires de ligne commencent par // et les commentaires de bloc sont encadrés par /* et */ . La grammaire autorise l’imbrication des commentaires de bloc. Dans le dépôt, /// sert de convention pour les commentaires de documentation. Littéraux numériques Forme Exemple Usage Décimal 42 , 1_000 Entier en base 10 ; le souligné sépare les chiffres. Binaire 0b101010 Préfixe 0b ou 0B . Octal 0o52 Préfixe 0o ou 0O . Hexadécimal 0x2A Préfixe 0x ou 0X . Flottant décimal 3.5 , 1e6 Fraction et/ou exposant décimal. Flottant hexadécimal 0x1.8p2 Mantisse hexadécimale et exposant en puissance de deux. Le type concret d’un littéral dépend du contexte et de l’analyse de types. Ne déduis pas sa largeur du seul nombre de chiffres ; annote le type ou utilise une conversion explicite lorsque l’API l’exige. Chaînes, caractères et échappements Une chaîne utilise des guillemets doubles et un caractère utilise des apostrophes. Les caractères de fin de ligne ne sont pas écrits littéralement dans ces tokens ; ils s’introduisent avec un échappement. Les échappements définis comprennent la barre oblique inversée, les guillemets, \n , \r , \t , \0 , les caractères de contrôle ainsi que les formes hexadécimales \xNN , \uNNNN et \UNNNNNNNN . let message: string = "ligne 1\nligne 2";let initiale: char = 'V'; Notation EBNF utilisée ::= signifie « est défini par ». | sépare des choix. [ ... ] rend un élément facultatif. { ... } indique une répétition, éventuellement vide. Ce que les tests confirment Élément Dans l’EBNF Analyseur vérifié Compilation / exécution Mots-clés, opérateurs et tokens Liste et opérateurs documentés. check-ebnf-frontend-sync vérifie leur présence dans le lexer et la couverture des tokens par le parseur. Ce contrôle ne teste ni typage ni génération de code. Littéraux et expression de base Décrits dans le fichier EBNF. Fixture expression_literals_parse.vit validée par test-grammar . Des entiers, booléens, chaînes et flottants apparaissent dans des programmes runtime ; tous les échappements lexicaux ne sont pas couverts par ces seuls tests. form , pick , let , marqueurs de référence Décrits. Fixtures form_parse , pick_parse , let_mut_ok et ref_param_type_marker_ok . Formes, tableaux et choix ont des tests backend/runtime ; la seule fixture de parsing ne prouve pas la compilation. as , attributs et gardes de match as et attributs absents ; gardes non exprimées par la règle EBNF des bras. Le test de parité accepte un attribut ; le sous-ensemble natif accepte casts et gardes. Les casts et plusieurs formes de match sont exécutés par les tests natifs. Nullable ?T , await , defer , pointeurs await /defer /pointeurs décrits ; ?T absent du type EBNF. Pas de fixture ciblée passée pour chacun dans les suites auditées. Non prouvé au backend/runtime. Fixtures et résultats détaillés : alignement grammaire/parseur , sous-ensemble natif et matrice de support . Ouvrir le fichier complet de grammaire sur GitHub → 02 DéclarationsModules, valeurs, procédures, types et déclarations avancées.OUVRIR LA PAGE → En-tête de module et import space outils::calcul;use core::types::option::{Option, option_some};use outils::conversion as conversion; space accepte un chemin. use peut importer un module ou un chemin, définir un alias avec as , importer un groupe de noms entre accolades ou demander un glob avec * . Les noms qualifiés utilisent :: . La résolution concrète dépend de la racine du projet et des chemins de modules configurés. Valeurs et types nommés export const REPONSE: i64 = 42;static COMPTEUR: i64 = 0;type Identifiant = u64;opaque Jeton; const et static déclarent des valeurs de module initialisées par une expression. type donne un alias à un type ; opaque annonce un type dont la représentation n’est pas exposée. Les règles détaillées de visibilité et de mutabilité se vérifient dans les étapes sémantiques du compilateur. Formes et choix form Point { x: i64, y: i64,}pick Etat { Inactif, Pret, Erreur(i64),} Une form contient des champs nommés. Un pick décrit des variantes, et la grammaire permet de placer des types entre parenthèses après une variante. Dans le langage courant, on emploie souvent les formes comme valeurs composées et les choix pour représenter des états exclusifs. Procédures export proc ajouter_un(valeur: i64) -> i64 requires valeur < 100; ensures result == valeur + 1;{ return valeur + 1;} Une procédure peut déclarer des paramètres typés, un type de retour, des paramètres génériques, une clause where et plusieurs contrats requires /ensures . Le corps est un bloc. Les paramètres n’ont pas de valeur par défaut dans la grammaire actuelle. Traits et implémentations Un trait contient des déclarations liées à un contrat de comportement. Un impl regroupe les déclarations d’implémentation pour un type et éventuellement un trait. Les méthodes peuvent employer &self ou &mut self ; la bibliothèque core en fournit des signatures. La liaison effective des implémentations de traits et le dispatch générique ne sont pas complets dans le compilateur d’après la documentation de core . export trait Display { proc fmt(&self, formatter: &mut Formatter) -> bool;} Frontières, macros et tests extern "bibliotheque" proc nom(...); déclare une procédure dont le corps est fourni à l’extérieur. intrinsic nom(...); réserve l’implémentation au compilateur ou au runtime. macro nom(...) { ... } déclare une macro selon la grammaire. test "nom" { ... } déclare un bloc de test. Les modificateurs prévus avant une déclaration comprennent pub , export , async , unsafe et comptime . La syntaxe reconnue ne garantit pas que chaque modificateur soit pris en charge de bout en bout. Vérification par construction Construction EBNF Analyseur Compilation constatée space / use Décrites. Acceptées par les tests d’import/parité. Import et appel qualifié compilés et exécutés dans llvm_imports_runtime.vit . export Décrit, y compris les listes et glob. Exercé dans les fixtures d’import/export. Des imports/exports de modules sont exécutés ; l’alias d’export emprunte le frontend de compatibilité. Chaque forme de réexport n’est pas validée. const / static Décrites. Une constante importée est exercée ; aucune fixture ciblée relevée pour static . Constantes utilisées par les tests d’import ; génération/exécution de static non prouvée ici. type / opaque Décrites. Pas de fixture ciblée retenue pour un alias de type ou une déclaration opaque. Non établi par les tests de compilation et d’exécution audités. form sans paramètre générique Décrite. Acceptée par fixtures grammaire, parité et frontend natif. Champs scalaires, imbriqués et tableaux : IR natif, C17 et exécution vérifiés. form<T> Décrite. Le cas test atteint la génération C. Rejetée au backend avec VITTE_BACKEND_E_CODEGEN dans le test ciblé. pick et variantes à charge utile Décrites. Acceptées par fixtures grammaire, parité et frontend natif. Variantes simples et charges utiles compilées et exécutées avec le backend natif. proc Décrite, avec paramètres et retour. Acceptée dans les cas de parité, séma et frontend natif. Compilée et exécutée dans plusieurs fixtures. requires / ensures Décrites. Vérifiées par test sémantique. contracts_ok.vit passe par compatibilité, compile et s’exécute. trait / impl / génériques / where Décrits. Le README du parseur bootstrap les documente ; pas de fixture runtime ciblée dans cet audit. Compilation de bout en bout non prouvée ; core signale des limites de liaison. extern / intrinsic / macro Décrites. Non vérifiées par une fixture ciblée retenue. Non prouvées en génération et exécution. test Décrite. Une déclaration test est acceptée par le test d’émetteur de compatibilité. L’émetteur C est testé ; la déclaration n’est pas exécutée comme un test Vitte. Attributs et modificateurs Les modificateurs cités dans l’EBNF sont décrits ; les attributs en sont absents. La parité accepte un attribut de procédure ; les modificateurs ne sont pas tous couverts. Support du backend non établi pour l’ensemble. Voir la matrice complète avec les fichiers de preuve et les commandes exécutées . Source syntaxique : grammaire EBNF . 03 TypesTypes primitifs, tableaux, références, pointeurs, alias et génériques.OUVRIR LA PAGE → Types primitifs documentés dans le registre bootstrap Famille Noms listés Notes Contrôle bool , void , never , error Valeurs logiques, absence de résultat, absence normale de retour et valeur d’erreur. Entiers u8 , u32 , u64 , usize , int , i64 Le registre bootstrap n’énumère qu’un sous-ensemble ; les modules et fixtures emploient aussi des types plus larges. Flottants f32 , f64 Valeurs à virgule flottante. Texte string Chaîne dans les interfaces intégrées. Cette liste vient du registre décrit dans src/bootstrap/builtin/README.md . Elle n’est pas exhaustive : les tests compilés utilisent aussi plusieurs autres largeurs entières et char . Types composés et qualifiés [4]i64 // tableau fixe de quatre entiers&Point // référence&mut Point // référence mutable*u8 // pointeurmodule::Point // type qualifié La grammaire décrit les références avec &T ou ref T , éventuellement suivies de mut ; les pointeurs avec *T ; les tableaux avec [expression]T ; et les chemins de type avec des paramètres génériques entre chevrons ou crochets. Génériques et alias type Option<T> = ?T;form Paire<T> { premier: T, second: T,}proc identite<T>(valeur: T) -> T { return valeur;} Les paramètres génériques rendent un type ou une procédure réutilisable pour plusieurs types. La grammaire prévoit une contrainte après : et des clauses where . Les sources de core utilisent des types génériques, mais le test de compilation natif rejette explicitement une forme générique Box<T> au backend. Le code ci-dessus sert à illustrer la syntaxe visée ; il n’est pas une promesse de compilation. Nullable : écart à résoudre entre les sources Les sources de modules/core emploient le type nullable ?T et représentent l’absence avec null . Toutefois, la production type de grammar/vitte.ebnf ne liste pas explicitement cette forme. Aucun des tests d’exécution audités ne prouve son acceptation et sa génération C17 ; l’exemple suivant illustre le code source de core , pas une forme garantie par l’EBNF ou le backend natif. proc valeur_ou_zero(valeur: ?i64) -> i64 { if valeur != null { return valeur; } return 0;} Conversions Le mot de conversion as est accepté et compilé dans les tests natifs, notamment pour convertir des valeurs en u8 et f64 . Il n’apparaît pas dans la production d’expression de l’EBNF actuelle. Une conversion explicite annonce le changement de type ; elle ne prouve pas à elle seule que la valeur reste dans la plage de destination. La bibliothèque core::convert fournit des conversions vérifiées pour certains couples de types. Vérification par famille de types Construction EBNF Analyseur Compilation constatée Booléens, entiers signés/non signés, string Les types nommés passent par path_type . Acceptés dans les fixtures natives et bootstrap. Oui : booléens, largeurs entières et chaînes sont exercés dans les 11 fixtures runtime. f64 et conversions numériques Les noms de type et cast sont des chemins syntaxiques ; as est absent de l’EBNF. as accepté dans une fixture runtime. Oui : llvm_integer_width_runtime.vit compile puis exécute une conversion vers f64 . Tableaux fixes, tableaux imbriqués, index Décrits par [expression]type . Acceptés ; erreurs de taille et de type également testées. Oui : HIR/IR, C17 et exécution pour lectures, écritures et matrices. Références et champs de formes Décrits par &T et ref T . Marqueurs de paramètre couverts par fixture ; formes et champs couverts dans le frontend natif. Oui pour références à des formes et accès de champs dans aggregate_runtime.vit . Pointeurs *T Décrits. Pas de fixture ciblée d’analyse retenue. Non prouvé dans le runtime audité. Génériques et contraintes Décrits par paramètres génériques et clauses where . Le parseur bootstrap les documente ; les cas natifs testés ne valident pas un générique complet. Forme générique explicitement rejetée au backend ; autres combinaisons non prouvées. Nullable ?T Absent de la production EBNF type . Utilisé dans les sources core , sans fixture ciblée de parseur dans les tests exécutés. Non prouvé. Cast valeur as T Absent de l’EBNF. Accepté par le frontend natif des tests. Oui pour les casts vers u8 et f64 exercés en runtime. La matrice générale du support donne les commandes de vérification et distingue le frontend natif du chemin bootstrap. Règle de consultation Utilise le type le plus étroit qui exprime réellement ton domaine, puis vérifie la disponibilité et les règles de conversion sur la cible de compilation utilisée. Sources : grammaire EBNF · registre des types intégrés · contrats de core . 04 Expressions et opérateursPriorité, associativité, conversions, accès et appels.OUVRIR LA PAGE → Priorité des opérateurs Le tableau va du niveau le moins prioritaire au plus prioritaire. Les opérateurs d’un même niveau se regroupent de gauche à droite, sauf l’affectation et ?? , définis récursivement vers la droite. Niveau Opérateurs Exemple ou rôle Affectation = += -= *= /= %= &= |= ^= <<= >>= Modifie une cible ; l’assignation composée combine calcul et affectation. Coalescence ?? Valeur de repli associée vers la droite. OU logique or || Combine des conditions. ET logique and && Combine des conditions. OU binaire | Opération bit à bit. OU exclusif ^ Opération bit à bit. ET binaire & Opération bit à bit. Égalité == != Compare l’égalité ou la différence. Comparaison < <= > >= Compare un ordre. Décalage << >> Décale les bits d’une valeur entière. Addition + - Addition et soustraction. Multiplication * / % Multiplication, division et reste. Plages .. ..= Construit une plage ouverte ou incluant la borne finale. Préfixe unaire + - ! ~ * & not move ref await Signe, négation, bits, déréférence, référence ou opération de contexte. Postfixe Appel, [indice] , .champ , ? Appel, indexation, accès de champ ou suffixe optionnel. Associativité et parenthèses Les expressions arithmétiques et logiques forment des chaînes de gauche à droite. L’affectation s’associe vers la droite. Les parenthèses forcent le regroupement voulu et restent utiles même quand la priorité du langage suffirait : let a: i64 = 2 + 3 * 4; // multiplication d'abordlet b: i64 = (2 + 3) * 4; // addition d'abord La grammaire n’énonce pas à elle seule tous les effets d’évaluation ni toutes les règles de typage. Pour des opérandes qui modifient l’état, découpe l’expression en plusieurs instructions afin d’éviter une dépendance implicite à l’ordre d’évaluation. Familles d’expressions Expressions primaires : littéraux, chemins, self , listes de valeurs entre crochets, parenthèses et blocs. Postfixes : appels, accès indexé, champs et suffixe ? . Unaires : signes, négation logique/bit à bit, déréférence, emprunt, move , ref , await . Binaires : arithmétique, plages, décalages, bits, comparaisons et logique. Affectations : expression simple et formes composées définies dans la grammaire. Écarts syntaxe / compilation à connaître as Type apparaît dans les sources et les tests compilés, mais pas dans la production expression du fichier EBNF canonique. Les gardes de motifs et les formes avancées de match ont le même écart : le frontend natif les accepte dans ses tests, alors que cette production EBNF ne décrit qu’un bras simple expression => ... . Vérification par famille d’expressions Construction EBNF Analyseur Compilation constatée Arithmétique, bits, comparaisons et logique Décrits avec les niveaux de priorité du tableau. Acceptés ; cas de types incompatibles rejetés avec diagnostic testé. Oui : calcul arithmétique, comparaisons et logique compilés et exécutés avec le frontend natif. Affectations = , += , etc. Décrites. Acceptées ; l’affectation à une liaison immuable est rejetée par le test sémantique. Oui : += et -= compilés et exécutés par le backend natif. Appels, accès de champ et indexation Décrits dans les formes postfixes. Acceptés dans les fixtures d’agrégats et de tableaux. Oui : appels, champs imbriqués et index de tableaux en IR/C17/exécution. Cast as Type Non décrit dans l’EBNF. Accepté dans les cas natifs vers u8 et f64 . Oui pour ces exemples testés en runtime. Plages .. / ..= Décrites. Le test ciblé du for sur tableau confirme un diagnostic de codegen, pas le comportement de toutes les plages. Exécution d’une boucle for sur plage non établie par les 11 fixtures runtime. Coalescence ?? , suffixe ? , await , move Décrits par l’EBNF. Pas de fixture ciblée passée pour chacune de ces formes. Non prouvé au backend et à l’exécution. Gardes, variantes qualifiées et charges utiles de match Les variantes simples de bras sont décrites ; gardes et motifs de charge utile ne le sont pas complètement. Acceptés par les cas du frontend natif. Oui : variantes simples et charges utiles passent IR, C17 et exécution. Grammaire canonique · Tests du frontend natif · État du support . 05 Instructions et contrôleVariables, affectation, conditions, boucles, match et assertions.OUVRIR LA PAGE → Variables locales et affectation let reponse: i64 = 42;let mut compteur: i64 = 0;set compteur = compteur + 1; let peut préciser mut , un type, une valeur initiale, ou les deux. set introduit une expression d’affectation. Une liaison immuable ne doit pas être modifiée ; les règles exactes sont vérifiées lors de l’analyse sémantique. Retour et fin de boucle return expression; et give expression; renvoient une valeur ; les formes sans expression terminent une procédure sans résultat. break; sort de la boucle courante. continue; passe au prochain cycle de la boucle courante. Conditions et répétitions if pret { traiter();} elif en_attente { patienter();} else { terminer();}while indice < 4 { set indice = indice + 1;}for valeur in 0..4 { utiliser(valeur);} La grammaire prévoit if /elif /else , while , loop et for nom in expression . Les exemples de bibliothèque parcourent des plages demi-ouvertes : 0..4 contient 0 à 3. Les types de séquences itérables disponibles restent dépendants de l’implémentation. Match match etat { Etat.Inactif => { afficher("arrêt"); }, Etat.Pret => { afficher("prêt"); },} Les bras de la grammaire ont la forme expression => bloc-ou-expression , séparés par des virgules. La production formelle accepte des expressions de bras ; ne suppose pas la prise en charge de motifs plus riches sans confirmation dans l’analyseur et le compilateur. Assertions, différé, unsafe et assembleur assert(expression); vérifie une propriété à un point donné. defer expression; ou defer { ... } marque une action différée ; vérifie le moment d’exécution garanti par le compilateur ciblé. unsafe { ... } délimite un bloc qui exige des garanties manuelles. asm(...); et asm "..."; sont les formes d’assembleur admises par la grammaire. La grammaire ne prouve pas la sûreté Un bloc unsafe , une assertion ou une instruction reconnue ne garantit ni l’absence de dépassement ni le support par le backend. Vérification par instruction Instruction EBNF Analyseur Compilation constatée let , let mut , set Décrites. Acceptées ; test natif confirme aussi le rejet de set sans affectation. Oui : liaisons, mutation locale, champs et index de tableau passent l’IR/C17 et l’exécution. return / give Les deux formes sont décrites. return est utilisé dans toutes les suites ; fixture dédiée à give non relevée. return est largement compilé ; give non prouvé séparément. if / elif / else Décrites. if /else sont testés ; la parité de elif n’a pas de cas runtime retenu. Oui pour conditions et sélection de valeurs dans les fixtures runtime. while , break , continue Décrites. Acceptées dans les fixtures d’exécution. Oui : boucles et cibles de sortie/continuation compilées et exécutées. loop Décrite. Pas de fixture ciblée dans les suites exécutées pour cette forme exacte. Non prouvé. for nom in expression Décrit. La syntaxe atteint le diagnostic backend dans le cas d’un tableau. for nom in tableau est rejeté avec VITTE_BACKEND_E_CODEGEN . L’exécution d’une boucle for sur plage n’est pas prouvée par l’audit. match simple et variantes à charge utile match et les bras simples sont décrits ; gardes/motifs sont des extensions par rapport à l’EBNF. Acceptés dans les fixtures natives, y compris motifs de variantes et joker. Oui : IR, C17 et exécution de choix simples et à charge utile. assert Décrite. Syntaxe listée ; pas de fixture isolée de cette instruction dans les tests runtime retenus. Non prouvé comme instruction au backend dans cet audit. defer , unsafe , asm Décrites. Pas de fixture représentative identifiée pour chacun. Non prouvé au backend et à l’exécution. Sources : grammaire EBNF · tests du frontend natif · liste des fixtures runtime · matrice générale . 06 Modules et visibilitéChemins, imports, alias, exports et organisation multi-fichiers.OUVRIR LA PAGE → Nommer un module space outils::calcul; La grammaire permet des segments séparés par :: ou / . Le manifeste JSON documente :: comme syntaxe de chemin de module. Garde les noms de fichier, le chemin logique space , les imports et le manifeste du paquet cohérents. Importer use core::types::option::{Option, option_some};use outils::calcul as calcul;use outils::math::*; use prend un chemin, un alias, un groupe de noms ou un glob. Les alias donnent un nom local ; les imports globaux font entrer plusieurs symboles dans la portée et peuvent rendre leur provenance ambiguë. Préfère les imports explicites dans une API que d’autres personnes doivent relire. Exporter export const REPONSE: i64 = 42;export proc calculer() -> i64 { return REPONSE; }export { REPONSE, calculer }; La grammaire fournit des formes d’export de déclaration et des listes d’exports. Le compilateur a des limites sur certains réexports ; un nom accessible localement n’est pas nécessairement réexportable depuis un autre module. Résolution et visibilité Un nom qualifié comme json::parser::parser donne la provenance d’une déclaration. L’importeur recherche les modules dans des racines configurées. Le CLI documente notamment VITTE_MODULE_PATH pour ajouter des racines et --manifest-path /--project-root pour préciser le projet. La documentation de core indique que les imports doivent actuellement venir du chemin complet : core::prelude ne fournit pas une façade complète par réexport. Pour diagnostiquer un import, vérifie successivement le chemin logique, la racine de résolution, l’existence du fichier et l’export du symbole utilisé. Organisation de paquet Le paquet JSON fournit un exemple de manifeste package.toml avec nom, version, fichier d’entrée, racine du module et syntaxe de chemin. Consulte sa documentation de paquet pour l’installation et l’utilisation de VITTE_MODULE_PATH . Vérification des constructions de module Construction EBNF Analyseur et résolution Compilation constatée space chemin; Décrite, avec segments :: ou / . Acceptée dans les fixtures de modules/parité. Oui : des modules avec chemins déclarés sont compilés dans les suites runtime. use chemin et appel qualifié Décrits. Import résolu par le test d’import natif/bootstrap. Oui : llvm_imports_runtime.vit importe un module, appelle ses procédures et s’exécute. Alias use chemin as nom Décrit. Accepté dans le fichier runtime d’import. Oui : l’alias imported est utilisé pour des appels compilés et exécutés. Imports groupés et glob Décrits dans la production use . Les fixtures d’import couvrent plusieurs formes, mais chaque variante n’a pas été lancée comme programme runtime dans l’audit. Non prouvé pour tous les groupes/globs ; consulter les fixtures d’import/visibilité. export de déclaration Décrit. Exercé par les modules de test et l’analyse sémantique. Des valeurs exportées sont importées dans les tests runtime ; toutes les déclarations ne sont pas couvertes. Réexport avec alias ou chemin La grammaire décrit les formes d’export. Le pipeline de CLI route les alias d’export vers la compatibilité ; le parseur bootstrap documente le rejet de certains réexports de module. Non prouvé en exécution pour les réexports généraux. Imports qualifiés ambigus La forme syntaxique de l’import existe. La cible import_collision/modules_main.vit est explicitement ignorée dans test-sema , car la résolution sémantique des collisions qualifiées reste incomplète. Non confirmé ; un nom importé en collision ne doit pas être considéré comme résolu de façon garantie. Racines de projet et manifeste Hors grammaire du langage. Options CLI documentées ; exemples dans les tests de projet/modules. La résolution de module est exécutée par une fixture ; chaque combinaison de manifeste/racine n’est pas couverte. Cette table distingue une syntaxe acceptée d’un module effectivement résolu. Voir la matrice globale du compilateur et la fiche CLI . 07 Intégrés et types primitifsTypes, constantes, procédures et opérateurs de la table intégrée.OUVRIR LA PAGE → Contexte du registre La liste ci-dessous est celle de src/bootstrap/builtin/README.md . Elle décrit le registre bootstrap, pas nécessairement chaque type que la grammaire, les fixtures ou un autre backend peuvent accepter. Types intégrés listés Famille Types Contrôle et diagnostic void , never , error , bool Entiers u8 , u32 , u64 , usize , int , i64 Flottants f32 , f64 Texte string Les modules et tests du dépôt utilisent également des types tels que i8 , i16 , i32 , u16 , char et d’autres. Ce décalage doit être vérifié contre la table builtin réellement compilée avant d’afficher une liste exhaustive. Constantes et procédures Nom Signature Rôle true , false bool Littéraux booléens. print , println (string) -> void Écriture de texte standard, avec ou sans saut de ligne. eprint , eprintln (string) -> void Écriture sur le flux d’erreur, avec ou sans saut de ligne. panic (string) -> never Arrêt anormal avec un message. assert (bool) -> void Vérification d’une condition. len (string) -> usize Longueur selon le contrat du builtin. to_string (int) -> string Conversion d’un entier en texte. type_name (error) -> string Nom de type associé au diagnostic intégré. Opérateurs du registre Numériques : + - * / % . Entiers et bits : & | ^ << >> . Comparaison : == != < <= > >= . Logique : and or . Unaires : ! + - ~ . Le registre indique que les opérations numériques et binaires attendent actuellement des types d’opérandes correspondants. La table ne remplace ni les règles complètes de typage ni la priorité définie par la grammaire. Vérification des intégrés Intégré Registre Parseur / sémantique Compilation constatée true , false , entiers, booléens, chaînes Types/littéraux décrits. Exercés par les fixtures natives et runtime. Oui : types et littéraux passent par C17 et exécution. print , println , eprint , eprintln , panic , assert Listés comme procédures intégrées. Les appels sont des expressions d’appel ; le backend documente ce sous-ensemble de builtins. Émission C17 documentée par le backend ; exécution ciblée de chaque appel non prouvée par les 11 fixtures runtime. len Listé. Accepté dans les tests chaîne. Oui : compilé et exécuté avec string_intrinsics_runtime.vit . trim , starts_with , ends_with Ne figurent pas dans la liste builtin bootstrap citée plus haut. Le pipeline les route vers compatibilité. Oui : string_intrinsics_runtime.vit compile et s’exécute via le chemin compatibilité. to_string , type_name Listés dans le registre bootstrap. Pas de fixture d’analyse dédiée retenue. Non établis par les tests runtime audités ; ne pas inférer leur support C17 depuis leur seule présence dans le registre. Sources : registre builtin bootstrap · builtins documentés par le backend C17 · fixture runtime de chaînes · priorité des expressions . 08 CLI et diagnosticsCommandes, options principales, vérification et lecture des erreurs.OUVRIR LA PAGE → Commandes principales Commande Usage Indication dans le dépôt vitte --version Afficher la version. Vérification rapide de l’installation. vitte lex fichier.vit Afficher les tokens. Explorer le découpage lexical. vitte parse fichier.vit Analyser la syntaxe. Vérifier la structure d’un fichier. vitte check fichier.vit Vérifier le fichier. Le frontend natif vérifie son sous-ensemble ; d’autres sources suivent la compatibilité. La suite native teste 9 cas valides et 18 erreurs attendues. vitte compile fichier.vit --stop-after-sema Arrêter après l’analyse sémantique. Commande vérifiée par test-sema sur procédures, imports et contrats. vitte compile fichier.vit Compiler le programme. HIR/IR/C17 natifs validés pour formes, tableaux, choix et opérations scalaires ; génériques et autres formes avancées restent limités. vitte run fichier.vit Compiler et exécuter. Onze fixtures runtime du Makefile compilent et s’exécutent ; cette liste n’est pas une couverture complète du langage. vitte explain E0501 Expliquer un code de diagnostic public. Les codes publics incluent des préfixes E , W , N et H . Construire depuis le dépôt makevitte --versionvitte check examples/hello.vit Le dépôt utilise un frontend natif pour un sous-ensemble et un chemin bootstrap/compatibilité pour certaines sources. Le README racine et src/docs/language_coverage.md ne reflètent pas tous le même état que les tests et le README du driver ; la matrice État du support indique les preuves à privilégier. Options utiles du CLI documenté --diagnostic=terminal|json|sarif|lsp choisit le format du diagnostic. --stop-after-lexer , --stop-after-parser , --stop-after-sema arrêtent le pipeline à une étape. --emit-tokens , --emit-ast , --emit-hir , --emit-ir , --emit-c demandent des sorties intermédiaires lorsque l’étape est disponible. --target , --backend , --profile et -o configurent cible, backend, profil et fichier de sortie. --manifest-path , --project-root et VITTE_MODULE_PATH aident à résoudre la configuration et les modules. La présence d’une option dans l’aide ne garantit pas que chaque construction soit acceptée ou puisse produire un exécutable. Les tests runtime vérifient des programmes précis ; consulte les matrices par construction avant de dépendre d’une fonctionnalité. Lire un diagnostic Lis le code et le titre : ils identifient la classe du problème. Vérifie la phase et l’emplacement dans la source. Lis les notes et suggestions qui accompagnent le message. Corrige d’abord l’erreur la plus proche de sa cause ; les erreurs suivantes peuvent en découler. Documentation CLI détaillée · README du dépôt . 09 État du supportDistinguer grammaire acceptée, analyse, compilation et exécution.OUVRIR LA PAGE → Le 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. check inclut le parsing, puis continue vers la sémantique. Compilation : HIR/IR + C17 + exécution est une preuve du backend natif ; compatibilité + exécution passe 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 pick avec charge utile. Il vérifie aussi le rejet backend d’une forme générique et d’une boucle for sur 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. Sources du dépôt Grammaire EBNF et contrôle de synchronisation . Tests du sous-ensemble natif , parité des parseurs et cibles de vérification et runtime . Sélection du frontend par la CLI , capacités documentées du parseur bootstrap et chemin de compilation natif . 10 Bibliothèques core et JSONOrganisation de core, contrats d’API et utilisation du module JSON.OUVRIR LA PAGE → Bibliothèque fondamentale core core rassemble les primitives et algorithmes fondamentaux ; les conteneurs propriétaires et alloués appartiennent au paquet alloc . Le README organise les modules de core ainsi : Familles Contenu types , traits , marker , ops Types fondamentaux, contrats, marqueurs et opérations. primitive , cmp , convert , num Types primitifs, comparaisons, conversions et arithmétique. array , slice , iter , str Algorithmes sur tableaux, tranches, itérateurs et texte empruntés. mem , ptr , intrinsics Mémoire, pointeurs et opérations dépendantes du compilateur. fmt , hash , error , sync , cell Formatage, hachage, erreurs, synchronisation et cellules. Exemple d’import direct : use core::types::option::{Option, option_some, option_is_some};use core::slice::search::{slice_find_index}; Index des APIs exportées · Contrats et limites de core . L’index API est généré depuis les déclarations exportées ; le README précise qu’il s’agit d’un contrat source, pas d’une garantie d’ABI stable. Il signale également des éléments génériques et des traits qui restent à relier au compilateur natif. Module json Le module JSON propose une chaîne de traitement texte → tokens → valeurs → texte JSON. La documentation du module JSON présente les entrées du parser, le modèle JsonValue , l’encodeur, les erreurs, Unicode, les nombres et les limites documentées. use json::parser::parser::*;use json::encode::encoder::*; Le paquet s’appuie sur un manifeste package.toml et peut être découvert via VITTE_MODULE_PATH . Le guide détaillé se trouve dans modules/json/DOCUMENTATION.md ; le répertoire du module contient aussi les sources et les tests. Avant d’utiliser une API Vérifie le module et le chemin complet de l’import. Lis le commentaire et le contrat de la procédure, surtout pour les erreurs et les buffers. Regarde si elle utilise des intrinsics ou des formes génériques dont le backend dépend. Compile un exemple minimal avec la version et la cible de ton projet. 11 Module JSONParser, valeurs, objets, tableaux, encodeur, Unicode et diagnostics.OUVRIR LA PAGE → Le code de cette révision est la référence de l’API. L’issue #17 joint plusieurs éditions PDF. Le PDF français se présente comme une édition de travail et précise que ses signatures et commandes n’ont pas été vérifiées sur une copie du dépôt. Cette page s’appuie sur modules/json/DOCUMENTATION.md et les sources du module. La chaîne de traitement Le paquet json est écrit en Vitte et ne déclare pas de dépendance native dans package.toml . Le chemin ordinaire transforme un texte en tokens, construit une valeur Vitte, puis peut réencoder cette valeur : texte JSON → lexer → tokens → parser → JsonValue → encodeur → texte JSON Espace Rôle Point d’entrée utile json::core::value Valeurs, membres, constructeurs, accès, égalité et validation. JsonValue , JsonValueKind json::parser::parser Lexer puis lecture d’un document complet et production de diagnostics. parse , parse_strict json::encode::encoder Sérialisation compacte ou mise en forme lisible. encode , encode_pretty json::lexer Tokens et séquences d’échappement JSON. lex , decode_escape json::error Positions, plages source et modèles de diagnostic. JsonSpan , human_line json::runtime::numeric Validation, conversion et formatage des nombres JSON. parse_i64 , parse_f64 Installer et importer Depuis la racine du dépôt, les sources du module sont sous modules/json . Pour les compiler avec le compilateur du dépôt, indique le répertoire qui contient le namespace json : VITTE_MODULE_PATH="$PWD/modules" build/bin/vitte compile application.vit -o application Une installation du paquet depuis la racine du dépôt se fait avec : make -C modules/json install PREFIX="$HOME/.local" Le manifeste modules/json/package.toml nomme le paquet json , indique json.vit comme entrée et définit la syntaxe de chemin de module avec :: . Le manifeste décrit le paquet ; il ne constitue pas un gestionnaire de dépendances Vitte. Lire, puis vérifier le résultat Les opérations renvoient des formes de résultat avec un champ ok . Vérifie-le avant de lire value , text ou un autre contenu de sortie. Voici le flux d’usage présenté dans le guide du module : use json::parser::parser::{JsonParseResult, parse_strict};use json::encode::encoder::{JsonEncodeResult, encode_pretty};proc reformater(source: string) { let parsed: JsonParseResult = parse_strict(source); if !parsed.ok { // parsed.diagnostic donne le détail de l’échec. give; } let encoded: JsonEncodeResult = encode_pretty(&parsed.value); if !encoded.ok { // Ne pas utiliser encoded.text en cas d’échec. give; } // encoded.text contient le JSON mis en forme. give;} Les valeurs JSON JsonValue représente null , les booléens, les nombres, les chaînes, les tableaux et les objets. Le module distingue les nombres entiers et flottants avec JsonValueKind.Integer et JsonValueKind.Float . Cette distinction aide à choisir les conversions sans transformer systématiquement tous les nombres en flottants. let absent: JsonValue = null();let actif: JsonValue = boolean(true);let nombre: JsonValue = integer(42);let mesure: JsonValue = floating(21.5);let texte: JsonValue = string("Vitte");let vide: JsonValue = empty_array();let version: JsonMember = member("version", integer(1));let paquet: JsonValue = object([version]); Pour inspecter une valeur, teste son genre avec is_null , is_bool , is_integer , is_float , is_string , is_array ou is_object . Les fonctions array_len , array_get_ref , object_len et object_get_ref donnent accès aux contenus. Vérifie le type et la présence des champs avant de les utiliser dans les règles métier de ton application. Le modèle conserve l’ordre de lecture des membres d’un objet pour l’encodage, mais l’égalité structurelle des objets ne dépend pas de cet ordre. L’ordre des éléments d’un tableau reste significatif. Parser et clés dupliquées parse(source) effectue le lexing et lit un document JSON complet. Il exige une valeur racine et rejette les tokens qui la suivent. parse_strict(source) applique la même grammaire, mais refuse les clés d’objet répétées. Les variantes parse_tokens et parse_tokens_strict prennent une suite de tokens déjà produite par le lexer. Pour les entrées de configuration ou de réseau, préfère parse_strict : si deux clés portent le même nom, différents consommateurs peuvent sinon retenir des valeurs différentes. JSON ne permet pas les commentaires, les clés non citées, les guillemets simples ou les virgules finales. Diagnostics et positions En cas d’échec, JsonParseResult.diagnostic contient entre autres le code, le message, le détail, une suggestion éventuelle, la valeur attendue et trouvée, la clé et un JsonSpan . Les suggestions sont informatives ; elles ne modifient pas automatiquement le document. Les coordonnées de JsonPosition sont comptées à partir de zéro. Pour afficher une ligne ou une colonne à une personne, utilise human_line et human_column , qui produisent des numéros commençant à un. Les plages source servent à pointer l’erreur ou les occurrences liées dans un éditeur. Encoder du JSON encode et encode_compact produisent une sortie compacte ; encode_pretty utilise une indentation de deux espaces. encode_pretty_with_indent(value, indent) choisit l’indentation. Le résultat JsonEncodeResult fournit ok , text et error : n’utilise text qu’après avoir vérifié ok . L’encodeur vérifie les valeurs, les nombres et les chaînes, refuse les clés dupliquées et impose une profondeur maximale. L’espace json::encode::escape fournit aussi des fonctions pour échapper ou citer une chaîne indépendamment d’un arbre JSON ; ne le confonds pas avec l’encodeur complet. Unicode, nombres et limites Le lexer reconnaît les échappements JSON, dont \uXXXX . Les paires de surrogates UTF-16 sont composées en scalaire Unicode ; les surrogates isolés sont refusés. Le runtime numérique expose notamment scan , valid , parse_i64 , parse_u64 , parse_f64 et les fonctions de formatage correspondantes. Les conversions refusent les dépassements et les résultats flottants non finis. Les valeurs par défaut inscrites dans parser/parser.vit sont une profondeur maximale de 512 , 1 048 576 valeurs, éléments de tableau ou membres d’objet, et une longueur maximale de clé de 16 777 216 . Le type JsonParserLimits est exposé, mais les quatre fonctions de parsing exportées utilisent les limites par défaut : le code actuel ne fournit pas d’entrée publique de parsing avec limites personnalisées. Une syntaxe valide n’est pas une validation métier. Pour une donnée non fiable, borne la taille du texte à l’entrée, vérifie ok , contrôle le type et les plages de chaque champ attendu, puis traite l’échec d’encodage. Les limites du parser ne remplacent pas les limites de taille de requête ou les règles de sécurité de ton application. Vérifier le module dans son dépôt Le Makefile du module propose des cibles pour vérifier les sources, les suites d’encodage, le parser, Unicode, les nombres et l’installation : make -C modules/json checkmake -C modules/json test-encode test-runtime test-invalid test-parse \ test-roundtrip test-string-concat test-unicode Cette page documente les cibles déclarées dans modules/json/Makefile ; elle ne signifie pas que ces suites ont été exécutées pour chaque version du compilateur. La matrice d’état du compilateur et les sources du dépôt permettent de vérifier la compatibilité de ta cible. Documentation complète et éditions PDF Guide détaillé dans le dépôt : API, diagnostics, cas d’usage, sécurité et référence rapide. README du paquet : imports, installation et compatibilité. PDF français joint à l’issue #17 · PDF anglais . Issue #17 : autres fichiers PDF et suivi de la documentation. Le PDF français porte lui-même la mention « édition de travail » et demande de vérifier ses signatures et commandes dans le dépôt. Utilise-le comme document pédagogique complémentaire, pas comme spécification des fonctions exportées. 12 GlossaireDéfinitions rapides des termes du langage et du compilateur.OUVRIR LA PAGE → Alias de type Nom supplémentaire qui désigne un type existant, déclaré avec type . AST Arbre syntaxique abstrait : représentation structurée obtenue après l’analyse grammaticale du source. Backend Étape qui transforme une représentation intermédiaire vers une cible, comme du code machine ou C17. Builtin Symbole intégré au compilateur, au runtime ou à la plateforme, plutôt que défini par une bibliothèque Vitte ordinaire. Contrat Précondition ou postcondition d’une procédure, exprimée avec requires ou ensures . Déclaration Construction qui introduit un nom ou une entité : procédure, type, constante, module ou autre élément de niveau supérieur. Expression Construction qui calcule ou désigne une valeur ; elle peut être utilisée dans une instruction ou comme argument. Forme (form ) Type composé constitué de champs nommés. Générique Déclaration paramétrée par un ou plusieurs types, pour réutiliser une logique à plusieurs types concrets. Grammaire Règles formelles qui précisent quelles suites de tokens forment une construction valide. HIR Représentation intermédiaire de haut niveau entre l’AST et les étapes de compilation suivantes. Implémentation (impl ) Bloc qui relie des déclarations à un type et éventuellement à un trait. Import Déclaration use qui rend un module ou un symbole accessible depuis le fichier courant. Invariant Propriété qui doit rester vraie pendant une opération ou à la frontière d’un bloc de code. Lexer Composant qui découpe le texte source en tokens. Module Unité nommée par space qui rassemble des déclarations et définit des frontières de visibilité. Nullable Type qui peut représenter une valeur présente ou l’absence, souvent notée ?T dans les sources de core . Parser Composant qui vérifie l’organisation des tokens selon la grammaire et construit l’AST. Portée Zone de code dans laquelle un nom est visible et peut être utilisé. Référence Accès à une valeur existante, noté par exemple &T ou &mut T . Sémantique Règles qui donnent leur sens aux constructions : résolution des noms, types, mutabilité et contraintes. Token Unité lexicale produite par le lexer : identifiant, mot-clé, opérateur, littéral ou ponctuation. Trait Contrat de comportement partagé par des types, déclaré avec trait . Type opaque Type dont les utilisateurs ne voient pas directement la représentation interne, déclaré avec opaque . Valeur intégrée Constante ou procédure fournie par le compilateur, par exemple un builtin recensé dans le registre. Sources : grammaire EBNF · documentation du compilateur et de la CLI .

Lire l’état du langage avec prudence

La grammaire décrit une syntaxe ; elle ne garantit pas que le compilateur complet l’analyse, la compile et l’exécute. Chaque page indique ses sources et les écarts connus dans le dépôt.