Trait Rule

Source

pub trait Rule: Send + Sync {
    // Required methods
    fn name(&self) -> &'static str;
    fn family(&self) -> RuleFamily;
    fn matches(&self, graph: &Graph, id: NodeId) -> bool;
    fn rewrite(
        &self,
        graph: &mut Graph,
        id: NodeId,
        remap: &mut HashMap<NodeId, NodeId>,
    );
}

Expand description

One graph-rewrite rule. A rule pairs a structural matcher with a rewriter that emits replacement nodes and records the (old_id → new_id) remapping so the driver can rewrite consumer input edges to point at the replacement.

Rules don’t need to update the layout side-table for view nodes they insert: Graph::push auto-populates layout for view ops from the input’s layout.

Rules don’t express ordering edges for destructive ops they emit (e.g. Op::Release); derive_ordering does that automatically at execution-plan time.

Required Methods§

Source

fn name(&self) -> &'static str

Stable, human-readable name. Shows up in panic messages and debug traces.

Source

fn family(&self) -> RuleFamily

Which family this rule belongs to. Determines pass ordering.

Source

fn matches(&self, graph: &Graph, id: NodeId) -> bool

Whether this rule can rewrite the node at id. Should be pure — same inputs, same answer. Called once per node per pass; the first matching rule wins.

Source

fn rewrite( &self, graph: &mut Graph, id: NodeId, remap: &mut HashMap<NodeId, NodeId>, )

Apply the rewrite: append fresh nodes to the graph, declare any side-effect roots if the rewrite emits side-effecting ops, and write remap.insert(id, replacement_id) so the driver can redirect consumer edges. Calling this method implies matches returned true for the same (graph, id) — rewriters can rely on the structure the matcher checked for.