Struct ScopeTree

pub struct ScopeTree {
    pub root_body: Option<HirId>,
    pub parent_map: FxIndexMap<Scope, (Scope, ScopeDepth)>,
    var_map: FxIndexMap<ItemLocalId, Scope>,
    pub rvalue_candidates: HirIdMap<RvalueCandidateType>,
    pub backwards_incompatible_scope: UnordMap<ItemLocalId, Scope>,
    pub yield_in_scope: UnordMap<Scope, Vec<YieldData>>,
}

The region scope tree encodes information about region relationships.

Fields

root_body: Option<HirId>

If not empty, this body is the root of this region hierarchy.

parent_map: FxIndexMap<Scope, (Scope, ScopeDepth)>

Maps from a scope ID to the enclosing scope id; this is usually corresponding to the lexical nesting, though in the case of closures the parent scope is the innermost conditional expression or repeating block. (Note that the enclosing scope ID for the block associated with a closure is the closure itself.)

var_map: FxIndexMap<ItemLocalId, Scope>

Maps from a variable or binding ID to the block in which that variable is declared.

rvalue_candidates: HirIdMap<RvalueCandidateType>

Identifies expressions which, if captured into a temporary, ought to have a temporary whose lifetime extends to the end of the enclosing block, and not the enclosing statement. Expressions that are not present in this table are not rvalue candidates. The set of rvalue candidates is computed during type check based on a traversal of the AST.

backwards_incompatible_scope: UnordMap<ItemLocalId, Scope>

Backwards incompatible scoping that will be introduced in future editions. This information is used later for linting to identify locals and temporary values that will receive backwards-incompatible drop orders.

yield_in_scope: UnordMap<Scope, Vec<YieldData>>

If there are any yield nested within a scope, this map stores the Span of the last one and its index in the postorder of the Visitor traversal on the HIR.

HIR Visitor postorder indexes might seem like a peculiar thing to care about. but it turns out that HIR bindings and the temporary results of HIR expressions are never storage-live at the end of HIR nodes with postorder indexes lower than theirs, and therefore don’t need to be suspended at yield-points at these indexes.

For an example, suppose we have some code such as:

    foo(f(), yield y, bar(g()))

With the HIR tree (calls numbered for expository purposes)

    Call#0(foo, [Call#1(f), Yield(y), Call#2(bar, Call#3(g))])

Obviously, the result of f() was created before the yield (and therefore needs to be kept valid over the yield) while the result of g() occurs after the yield (and therefore doesn’t). If we want to infer that, we can look at the postorder traversal:

    `foo` `f` Call#1 `y` Yield `bar` `g` Call#3 Call#2 Call#0

In which we can easily see that Call#1 occurs before the yield, and Call#3 after it.

To see that this method works, consider:

Let D be our binding/temporary and U be our other HIR node, with HIR-postorder(U) < HIR-postorder(D). Suppose, as in our example, U is the yield and D is one of the calls. Let’s show that D is storage-dead at U.

Remember that storage-live/storage-dead refers to the state of the storage, and does not consider moves/drop flags.

Then:

1. From the ordering guarantee of HIR visitors (see rustc_hir::intravisit), D does not dominate U.

2. Therefore, D is potentially storage-dead at U (because we might visit U without ever getting to D).

3. However, we guarantee that at each HIR point, each binding/temporary is always either always storage-live or always storage-dead. This is what is being guaranteed by terminating_scopes including all blocks where the count of executions is not guaranteed.

4. By 2. and 3., D is statically storage-dead at U, QED.

This property ought to not on (3) in an essential way – it is probably still correct even if we have “unrestricted” terminating scopes. However, why use the complicated proof when a simple one works?

A subtle thing: box expressions, such as box (&x, yield 2, &y). It might seem that a box expression creates a Box<T> temporary when it starts executing, at HIR-preorder(BOX-EXPR). That might be true in the MIR desugaring, but it is not important in the semantics.

The reason is that semantically, until the box expression returns, the values are still owned by their containing expressions. So we’ll see that &x.

Implementations

impl ScopeTree

pub fn record_scope_parent( &mut self, child: Scope, parent: Option<(Scope, ScopeDepth)>, )

pub fn record_var_scope(&mut self, var: ItemLocalId, lifetime: Scope)

pub fn record_rvalue_candidate( &mut self, var: HirId, candidate_type: RvalueCandidateType, )

pub fn opt_encl_scope(&self, id: Scope) -> Option<Scope>

Returns the narrowest scope that encloses id, if any.

pub fn var_scope(&self, var_id: ItemLocalId) -> Option<Scope>

Returns the lifetime of the local variable var_id, if any.

pub fn is_subscope_of(&self, subscope: Scope, superscope: Scope) -> bool

Returns true if subscope is equal to or is lexically nested inside superscope, and false otherwise.

Used by clippy.

pub fn yield_in_scope(&self, scope: Scope) -> Option<&[YieldData]>

Checks whether the given scope contains a yield. If so, returns Some(YieldData). If not, returns None.

Trait Implementations

impl<'tcx> ArenaAllocatable<'tcx> for ScopeTree

fn allocate_on(self, arena: &'tcx Arena<'tcx>) -> &'tcx mut Self

fn allocate_from_iter( arena: &'tcx Arena<'tcx>, iter: impl IntoIterator<Item = Self>, ) -> &'tcx mut [Self]

impl Debug for ScopeTree

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

Formats the value using the given formatter.

impl Default for ScopeTree

fn default() -> ScopeTree

Returns the “default value” for a type.

impl<'__ctx> HashStable<StableHashingContext<'__ctx>> for ScopeTree

fn hash_stable( &self, __hcx: &mut StableHashingContext<'__ctx>, __hasher: &mut StableHasher, )

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: 240 bytes