Manifeste ABI
Statut documentaire : reference — voir Maturité et preuves.
Rôle
Le manifeste ABI est la description lisible par machine qui relie la publication source au layout physique d'invocation. Il fournit assez d'informations pour le linking et l'exécution sans refléter les classes privées du moteur au runtime.
Le loader actuel consomme des manifestes JSON avec une description de cible validée et une liste de descripteurs de méthodes.
Contrat de cible
Le loader testé valide :
- schema version
2; - taille des pointeurs identique à celle attendue par l'hôte ;
- ordre des octets little-endian ;
- record packing égal à
1.
Toute incompatibilité échoue avant l'invocation native.
Contrat de méthode
Chaque méthode contient au minimum id, declaring type id, noms, signature canonique, call kind, besoin de receiver, taille/alignment du record d'arguments, paramètres et résultat.
Chaque paramètre porte nom, source type, ABI kind, type id, taille, nullabilité, ownership, offset, release policy et direction.
Vocabulaire du manifeste
Le loader reconnaît plus de types que l'executor générique n'en marshal actuellement. Il reconnaît aussi in, out, inout, alors que le builder actuel n'exécute que in.
Cette séparation permet au format de manifeste d'évoluer comme description stable sans prétendre que tous les backends d'exécution supportent immédiatement tout le vocabulaire.
Identifiants stables
Les descripteurs chargés sont enregistrés par identité d'invocation. La compilation/linking FPL peut donc résoudre un membre publié vers ce descripteur avant exécution.
nom source
-> résolution linker
-> invocation id stable
-> descripteur manifeste
-> exécution native
Pourquoi valider la cible
Un manifeste produit pour une autre largeur de pointeur ne peut pas être interprété sans risque par le marshaller packed actuel. Le loader le rejette explicitement pour éviter handles tronqués et offsets faux.
Utilisation par la génération de bindings
Pour générer un SDK public, le manifeste devrait être combiné à des métadonnées de capability. Une méthode présente syntaxiquement mais nécessitant un type non supporté par le binding sélectionné doit provoquer un diagnostic clair plutôt qu'une dégradation silencieuse vers un pointeur opaque.