pub struct Manifest<'a> {
pub type_name: &'a str,
pub doc: &'a str,
pub schema_version: u32,
pub layout: LayoutSpec,
pub fields: &'a [FieldSpec<'a>],
pub variants: &'a [VariantSpec<'a>],
pub evolution: EvolutionSpec<'a>,
}Expand description
The semantic manifest: the single source of truth drivers read.
Fields§
§type_name: &'a strFully spelled type name, e.g. "my_crate::User".
doc: &'a strThe type’s doc comment (joined /// lines), or "" if undocumented.
schema_version: u32Monotonic schema version (1 for the first revision).
layout: LayoutSpecIn-memory layout of the type.
fields: &'a [FieldSpec<'a>]Fields in declaration order (for a struct; empty for an enum).
variants: &'a [VariantSpec<'a>]Variants in declaration order (for a fieldless enum; empty for a struct).
evolution: EvolutionSpec<'a>How this version relates to its predecessor.
Implementations§
Source§impl Manifest<'_>
impl Manifest<'_>
Sourcepub const fn packed_field_bytes(&self) -> usize
pub const fn packed_field_bytes(&self) -> usize
Sum of the sizes of all fields, ignoring inter-field padding.
Sourcepub const fn padding_bytes(&self) -> usize
pub const fn padding_bytes(&self) -> usize
Bytes of top-level padding the compiler inserted between or after this
type’s own fields (size - Σ field sizes).
This counts only inter-field and trailing padding at this level. It does
not see padding nested inside a field’s own type, so a struct whose
only field is itself padded reports 0 here. A zerocopy driver therefore
uses this as a necessary cross-check, not as the sole proof of no padding
— the actual guarantee comes from zerocopy’s IntoBytes bound.
Sourcepub const fn is_gap_free(&self) -> bool
pub const fn is_gap_free(&self) -> bool
Whether the layout has no top-level padding holes (size equals the sum
of the field sizes). See Manifest::padding_bytes for the nested-padding
caveat: a gap-free top level can still wrap a field type that is itself
padded.
Sourcepub const fn extends(&self, prev: &Manifest<'_>) -> bool
pub const fn extends(&self, prev: &Manifest<'_>) -> bool
Whether self is a layout-compatible, append-only extension of prev:
every field of prev is still present under the same name, at the same
offset, size and type.
This is the compile-time precondition for evolving a type while keeping old readers valid — new fields may only be appended, never inserted, reordered, resized or retyped. Two strictnesses worth calling out:
- Name is part of the contract. Fields are matched by name, so a
renamed field — even at the same offset, size and type — counts as
absent and fails the check. That is stricter than raw byte layout (a
rename keeps the bytes) but correct for name-based formats; express a
rename as a migration (
rename_from), not as an extension. - Type is part of the contract. A field silently changed from
u32tof32keeps the same offset and size but reinterprets the bytes, so it must not pass.
Pair with assert_compatible!.