Skip to main content

Speculator

choir_queue::speculate

Trait Speculator 

Source 
pub trait Speculator: Send {
    // Required methods
    fn name(&self) -> &'static str;
    fn step(&mut self, base: &str, onto: &str, proposed: &str) -> Step;
    fn identity(&self, change: &Change) -> String;
    fn subject(&self, state: &str) -> ContentHash;
}
Expand description

How the queue puts one change on top of a speculative state.

Implementations own three things the queue deliberately does not know: what a merge is, when two changes are the same change, and how a state is named to CI.

Required Methods§

Source

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

Stable identifier, for reports and errors.

Source

fn step(&mut self, base: &str, onto: &str, proposed: &str) -> Step

Merges proposed — authored against base — onto onto.

base is passed rather than derived because a 3-way text merge has no way to find it, and merging against the train’s advanced tip instead would misread the proposal as reverting everything merged ahead of it. An implementation that can find its own merge base is free to ignore the argument, and git’s does.

Source

fn identity(&self, change: &Change) -> String

A position-independent identity for change.

The same logical edit authored against two different bases — before and after the train rewrote the tip under it — must produce the same identity, or a rebased resubmission lands twice.

Source

fn subject(&self, state: &str) -> ContentHash

The content hash naming state.

This is what CI is asked about and what a landing records as the workspace head, so the two cannot disagree about which tree a verdict was for. It is not a hash of our choosing: a git state must be named by its git oid, or every check written down is about an id no git client can resolve.

Implementors§