#[non_exhaustive]pub struct IrModule {
pub header: IrHeader,
pub strings: StringTable,
pub slots: SlotTable,
pub opcodes: Vec<u8>,
pub islands: IslandTableParsed,
/* private fields */
}Expand description
A fully parsed and validated IR module, ready for walking.
Marked #[non_exhaustive]: the module carries derived lookup indices that
must stay in sync with the tables, so it can only be built by parse.
Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.header: IrHeaderParsed 16-byte file header.
strings: StringTableThe module’s string table — every name, literal and attribute value.
slots: SlotTableThe module’s slot declarations, including their defaults.
opcodes: Vec<u8>Raw opcode stream; the walker interprets it on the fly.
islands: IslandTableParsedThe module’s island declarations.
Implementations§
Source§impl IrModule
impl IrModule
Sourcepub fn parse(data: &[u8]) -> Result<Self, IrError>
pub fn parse(data: &[u8]) -> Result<Self, IrError>
Parse a complete FMIR binary into a validated IrModule.
Sourcepub fn slot_entry(&self, slot_id: u16) -> Option<&SlotEntry>
pub fn slot_entry(&self, slot_id: u16) -> Option<&SlotEntry>
Look up a slot table entry by slot_id in O(1).
Sourcepub fn island_entry(&self, island_id: u16) -> Option<&IslandEntry>
pub fn island_entry(&self, island_id: u16) -> Option<&IslandEntry>
Look up an island table entry by island id in O(1).
Sourcepub fn validate(&self) -> Result<(), IrError>
pub fn validate(&self) -> Result<(), IrError>
Validate cross-table references and opcode-stream structure.
Runs once at parse time (O(n) in the bytecode length) so the walker can stay cheap and so malformed IR fails at load rather than rendering mystery HTML on some later request.
Sourcepub fn slot_id_by_name(&self, name: &str) -> Option<u16>
pub fn slot_id_by_name(&self, name: &str) -> Option<u16>
Look up a slot ID by its name. Returns None if no slot with that name exists.
DUPLICATE-NAME RULE: slot names are not required to be unique — the
compiler derives some of them per-element (text:<index>, attr:class)
rather than per-module — so a name can address more than one slot. The
whole crate resolves that collision the same way: the first entry in
slot-table order wins, here, in crate::slot::SlotData::from_json, and in the
walker’s island-props builder. They used to disagree three ways (first,
last, and last-by-ascending-slot-id), so setting a value by name filled
one slot and left its twin blank while the island’s props reported a
third answer.
Verified by: crates/forma-ir/src/parser.rs > “duplicate_slot_names_resolve_first_wins_everywhere”