Struct rustc_hir_analysis::check::generator_interior::drop_ranges::DropRangesBuilder

struct DropRangesBuilder {
    nodes: IndexVec<PostOrderId, NodeInfo>,
    tracked_value_map: FxHashMap<TrackedValue, TrackedValueIndex>,
    deferred_edges: Vec<(PostOrderId, HirId)>,
    post_order_map: HirIdMap<PostOrderId>,
}

Tracks information needed to compute drop ranges.

Fields

nodes: IndexVec<PostOrderId, NodeInfo>

The core of DropRangesBuilder is a set of nodes, which each represent one expression. We primarily refer to them by their index in a post-order traversal of the HIR tree, since this is what generator_interior uses to talk about yield positions.

This IndexVec keeps the relevant details for each node. See the NodeInfo struct for more details, but this information includes things such as the set of control-flow successors, which variables are dropped or reinitialized, and whether each variable has been inferred to be known-dropped or potentially reinitialized at each point.

tracked_value_map: FxHashMap<TrackedValue, TrackedValueIndex>

We refer to values whose drop state we are tracking by the HirId of where they are defined. Within a NodeInfo, however, we store the drop-state in a bit vector indexed by a HirIdIndex (see NodeInfo::drop_state). The hir_id_map field stores the mapping from HirIds to the HirIdIndex that is used to represent that value in bitvector.

deferred_edges: Vec<(PostOrderId, HirId)>

When building the control flow graph, we don’t always know the post-order index of the target node at the point we encounter it. For example, this happens with break and continue. In those cases, we store a pair of the PostOrderId of the source and the HirId of the target. Once we have gathered all of these edges, we make a pass over the set of deferred edges (see process_deferred_edges in cfg_build.rs), look up the PostOrderId for the target (since now the post-order index for all nodes is known), and add missing control flow edges.

post_order_map: HirIdMap<PostOrderId>

This maps HirIds of expressions to their post-order index. It is used in process_deferred_edges to correctly add back-edges.

Implementations

impl DropRangesBuilder

fn new(
    tracked_values: impl Iterator<Item = TrackedValue>,
    hir: Map<'_>,
    num_exprs: usize
) -> Self

fn tracked_value_index(&self, tracked_value: TrackedValue) -> TrackedValueIndex

fn add_node_mapping(&mut self, node_hir_id: HirId, post_order_id: PostOrderId)

Adds an entry in the mapping from HirIds to PostOrderIds

Needed so that add_control_edge_hir_id can work.

fn add_control_edge_hir_id(&mut self, from: PostOrderId, to: HirId)

Like add_control_edge, but uses a hir_id as the target.

This can be used for branches where we do not know the PostOrderId of the target yet, such as when handling break or continue.

fn drop_at(&mut self, value: TrackedValue, location: PostOrderId)

fn reinit_at(&mut self, value: TrackedValue, location: PostOrderId)

fn process_deferred_edges(&mut self)

Looks up PostOrderId for any control edges added by HirId and adds a proper edge for them.

Should be called after visiting the HIR but before solving the control flow, otherwise some edges will be missed.

impl DropRangesBuilder

pub fn propagate_to_fixpoint(&mut self)

fn compute_predecessors(&self) -> IndexVec<PostOrderId, Vec<PostOrderId>>

impl DropRangesBuilder

DropRanges keeps track of what values are definitely dropped at each point in the code.

Values of interest are defined by the hir_id of their place. Locations in code are identified by their index in the post-order traversal. At its core, DropRanges maps (hir_id, post_order_id) -> bool, where a true value indicates that the value is definitely dropped at the point of the node identified by post_order_id.

fn num_values(&self) -> usize

Returns the number of values (hir_ids) that are tracked

fn node_mut(&mut self, id: PostOrderId) -> &mut NodeInfo

fn add_control_edge(&mut self, from: PostOrderId, to: PostOrderId)

Trait Implementations

impl Debug for DropRangesBuilder

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

Formats the value using the given formatter.

Layout

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference’s “Type Layout” chapter for details on type layout guarantees.

Size: 136 bytes