Skip to content
EN FR

ABI manifest

Documentation status: reference — see Maturity and evidence.

Role

The ABI manifest is the machine-readable description that connects source-level publication to physical invocation. It carries enough information for linking and execution without reflecting private engine classes at runtime.

The current loader consumes JSON manifests with a validated target description and a list of method descriptors.

Target contract

The currently tested loader validates:

  • manifest schema version 2;
  • target pointer size equals the executing host expectation;
  • little-endian byte order;
  • record packing equal to 1.

A mismatch fails manifest loading before any native invocation occurs. This is especially important for pointer/handle layouts.

Method contract

Each method entry provides at least:

  • method id;
  • declaring type id;
  • public/qualified name;
  • canonical signature;
  • call kind;
  • receiver requirement;
  • argument record size;
  • argument record alignment;
  • parameter descriptors;
  • result descriptor.

Each parameter descriptor carries name, source type, ABI kind, type id, size, nullability, ownership, byte offset, release policy, and direction.

Supported manifest vocabulary

The loader recognizes a wider set of value kinds than the current generic executor marshals. This is intentional: the manifest format can evolve as a stable publication description while execution backends advertise/certify their supported subset.

It also recognizes all three parameter directions (in, out, inout) even though the current argument builder only executes in.

Stable identifiers

A loaded descriptor is registered by invocation identity. FPL compilation/linking can then resolve a source-level published member to that descriptor before execution.

This gives a useful separation:

source name
 -> linker resolution
 -> stable invocation id
 -> manifest descriptor
 -> native execution

The source spelling is for developers; the invocation id is the stable execution key.

Why target validation matters

A manifest generated for a different pointer width cannot safely be interpreted by the current packed-record marshaller. The loader therefore rejects the mismatch explicitly instead of risking truncated handles or shifted argument offsets.

The same fail-fast principle should be preserved as additional platform targets are certified.

Binding-generation use

For public SDK generation, the manifest should be combined with capability metadata. A method that is syntactically present but requires a value kind unsupported by the selected binding must fail generation or be omitted with an explicit diagnostic; it must not silently degrade to an opaque pointer.