pub struct NativeStack {
pub number: u64,
pub base: String,
pub layers: Vec<NativeStackLayer>,
}Expand description
A stack as the platform records it: its layers bottom first - the order it
lands in - and the branch the bottom one targets. Read-only here;
registering one is a separate step, gated behind stk.githubStacks.
Fields§
§number: u64The platform’s own number for the stack, for messages.
base: StringThe branch the bottom review targets.
layers: Vec<NativeStackLayer>Layers bottom first.
Verified live rather than assumed: registering three chained pull
requests (main <- p <- q <- r) lists them in exactly that order, and
POST /stacks/{n}/add appends - a fourth review arrives last. That
append-only behaviour is why plan_stack_registration will only
extend a stack the submitted line grew on top of; /add carries no
position, so it cannot express anything else.
Implementations§
Source§impl NativeStack
impl NativeStack
Sourcepub fn parent_is_current(&self, branch: &str) -> bool
pub fn parent_is_current(&self, branch: &str) -> bool
Whether this stack’s own answer for branch’s parent is still current.
It is not, once that parent’s own review has landed: the platform keeps
a landed layer listed, so the ordering keeps naming it forever, while
the platform has already retargeted branch away from it. The stack’s
base is always current - it is a branch, not a layer, and nothing
lands it out from under the stack.
Sourcepub fn parent_landed(&self, branch: &str, parent: &str) -> bool
pub fn parent_landed(&self, branch: &str, parent: &str) -> bool
Whether parent is branch’s own recorded predecessor and has
landed - so the platform has already moved this base off it and will
never put it back.
The exact case NativeStack::can_base_on stops accepting, which is
what makes the two complementary: some other landed layer says nothing
about where this review’s base went.
Sourcepub fn can_base_on(&self, branch: &str, parent: &str) -> bool
pub fn can_base_on(&self, branch: &str, parent: &str) -> bool
Whether this stack can still bring branch’s base to parent on its
own - parent is one of the two places the platform puts a base: the
layer recorded directly below branch, or the stack’s own base, which
is where every layer ends up once the ones beneath it land.
This is the question every caller has, and it needs the local parent
to answer. A base and a parent that disagree while the stack can still
close the gap is a chain part-way through unwinding: the platform
retargets each layer onto the stack’s base as the one below it lands,
and cleanup walks the local parents the same way. A parent the stack
cannot reach - a line re-rooted onto a release branch, say - is a
disagreement nothing will resolve, and callers say so instead of
waiting for it.
Sourcepub fn parent_of(&self, branch: &str) -> Option<&str>
pub fn parent_of(&self, branch: &str) -> Option<&str>
What branch stacks on according to the platform: the branch below it,
or the stack’s base when it is the bottom. None when the stack does
not hold branch at all.
Sourcepub fn position_of(&self, branch: &str) -> Option<u32>
pub fn position_of(&self, branch: &str) -> Option<u32>
Where branch sits in the stack, 1-based and bottom first - the same
number GraphQL reports as stackEntry.position. The one derivation
from this side, so the two sources cannot drift into disagreeing.
Sourcepub fn review_id_for(&self, branch: &str) -> Option<&str>
pub fn review_id_for(&self, branch: &str) -> Option<&str>
The review id recorded for branch, for messages.
Trait Implementations§
Source§impl Clone for NativeStack
impl Clone for NativeStack
Source§fn clone(&self) -> NativeStack
fn clone(&self) -> NativeStack
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more