Struct ActiveConfiguration 

pub struct ActiveConfiguration {
    pub chip: Chip,
    pub selected: Vec<usize>,
    pub options: Vec<GeneratorOptionItem>,
    pub flat_options: Vec<GeneratorOption>,
}

Fields

chip: Chip

The chip that is configured for

selected: Vec<usize>

The names of the selected options

options: Vec<GeneratorOptionItem>

The tree of all available options

flat_options: Vec<GeneratorOption>

All available option items (categories are not included), flattened to avoid the need for recursion.

Implementations

impl ActiveConfiguration

pub fn is_group_selected(&self, group: &str) -> bool

pub fn is_selected(&self, option: &str) -> bool

pub fn selected_index(&self, option: &str) -> Option<usize>

pub fn select(&mut self, option: &str)

pub fn select_idx(&mut self, idx: usize)

Selects the option at idx.

Negative requirements (!X) on this option force-deselect X if it’s currently selected. The deselection cascades: anything whose requirements are no longer met is dropped as well (there is no save/restore mechanism; swapped-out options simply disappear until the user re-enables them).

Positive requirements remain hard gates — if any of them is unmet the call is a no-op.

pub fn deselect_idx(&mut self, idx: usize)

Deselects the option at idx, then cascades: any remaining selection whose requirements were propped up by the one we just removed is dropped too. This is the counterpart to Self::select_idx’s cascade, and gives the user a predictable “clear, don’t save” experience when toggling off an option that others depend on (e.g. toggling probe-rs off clears panic-rtt-target).

pub fn would_force_deselect(&self, option: &GeneratorOption) -> Vec<String>

Returns the names of currently-selected options that would be force-deselected (directly or via cascade) if the user toggled the given option. Empty when toggling would be non-destructive.

Symmetric: works whether the option is currently selected (simulates deselect, reports cascade) or not (simulates select, reports same-group siblings, negative-requirement targets, and cascade). The option being toggled is never itself reported — only collateral damage.

Defensive short-circuit: if the option is currently unselected and cannot actually be toggled on (chip-mismatch or an unmet positive requirement), the toggle would be a no-op, so we return an empty list. We gate on Self::is_option_toggleable rather than the strict Self::is_option_active on purpose — a row whose only conflict is a negative requirement is toggleable (selecting it cascades the conflict out), and its cascade is exactly what callers want reported.

pub fn is_active(&self, item: &GeneratorOptionItem) -> bool

Returns whether an item is toggleable in the UI.

For a category, the category’s own requirements must be met (strict) and at least one descendant must itself be toggleable; for a leaf option this uses Self::is_option_toggleable, i.e. an option with an unmet !X is still considered reachable because selecting it would cascade X out.

This is the TUI-facing predicate. For strict validation (e.g. the CLI checking whether a user’s selection set is self-consistent), use Self::is_option_active directly.

pub fn is_option_active(&self, option: &GeneratorOption) -> bool

Strict “is this option consistent with the current selection?” predicate.

Returns true only when:

• the option is available for the current chip,
• every one of its requirements is satisfied (including negative ones), and
• no other currently-selected option has !{option.name} in its requires.

This is the right check for validation: the CLI (esp-generate --headless -o …) and the xtask regression harness rely on it to reject inconsistent selection sets. It is not the right check for “can the user click this row in the TUI” — that’s Self::is_option_toggleable, which permits negative-requirement conflicts on the understanding that selecting the row will cascade them out via Self::select_idx.

pub fn is_option_toggleable(&self, option: &GeneratorOption) -> bool

Permissive “can the user toggle this row in the TUI?” predicate.

Returns true when the option is available for the current chip and every positive requirement is met. Negative requirements (!X) are intentionally ignored here: the TUI treats them as force-deselect hints, not gates. Selecting a row in this state routes through Self::select_idx, which cascades the negative-requirement targets (and their dependents) out; use Self::would_force_deselect to preview that cascade.

Callers that care about full self-consistency (CLI validation, xtask coverage) must use Self::is_option_active instead.

pub fn can_be_disabled(&self, option: &str) -> bool

pub fn collect_relationships<'a>( &'a self, option: &'a GeneratorOptionItem, ) -> Relationships<'a>

Trait Implementations

impl Debug for ActiveConfiguration

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.