Enum rustc_resolve::late::lifetimes::Scope

enum Scope<'a> {
    Binder {
        lifetimes: FxIndexMap<ParamName, Region>,
        next_early_index: u32,
        track_lifetime_uses: bool,
        opaque_type_parent: bool,
        scope_type: BinderScopeType,
        hir_id: HirId,
        s: &'a Scope<'a>,
    },
    Body {
        id: BodyId,
        s: &'a Scope<'a>,
    },
    Elision {
        elide: Elide,
        s: &'a Scope<'a>,
    },
    ObjectLifetimeDefault {
        lifetime: Option<Region>,
        s: &'a Scope<'a>,
    },
    Supertrait {
        lifetimes: Vec<BoundVariableKind>,
        s: &'a Scope<'a>,
    },
    TraitRefBoundary {
        s: &'a Scope<'a>,
    },
    Root,
}

Variants

Binder

Declares lifetimes, and each can be early-bound or late-bound. The DebruijnIndex of late-bound lifetimes starts at 1 and it should be shifted by the number of Binders in between the declaration Binder and the location it’s referenced from.

Fields of Binder

lifetimes: FxIndexMap<ParamName, Region>

We use an IndexMap here because we want these lifetimes in order for diagnostics.

next_early_index: u32

if we extend this scope with another scope, what is the next index we should use for an early-bound region?

track_lifetime_uses: bool

Flag is set to true if, in this binder, '_ would be equivalent to a “single-use region”. This is true on impls, but not other kinds of items.

opaque_type_parent: bool

Whether or not this binder would serve as the parent binder for opaque types introduced within. For example:

    fn foo<'a>() -> impl for<'b> Trait<Item = impl Trait2<'a>>

Here, the opaque types we create for the impl Trait and impl Trait2 references will both have the foo item as their parent. When we get to impl Trait2, we find that it is nested within the for<> binder – this flag allows us to skip that when looking for the parent binder of the resulting opaque type.

scope_type: BinderScopeTypehir_id: HirId

The late bound vars for a given item are stored by HirId to be queried later. However, if we enter an elision scope, we have to later append the elided bound vars to the list and need to know what to append to.

s: &'a Scope<'a>

Body

Lifetimes introduced by a fn are scoped to the call-site for that fn, if this is a fn body, otherwise the original definitions are used. Unspecified lifetimes are inferred, unless an elision scope is nested, e.g., (&T, fn(&T) -> &T); becomes (&'_ T, for<'a> fn(&'a T) -> &'a T).

Fields of Body

id: BodyIds: &'a Scope<'a>

Elision

A scope which either determines unspecified lifetimes or errors on them (e.g., due to ambiguity). For more details, see Elide.

Fields of Elision

elide: Elides: &'a Scope<'a>

ObjectLifetimeDefault

Use a specific lifetime (if Some) or leave it unset (to be inferred in a function body or potentially error outside one), for the default choice of lifetime in a trait object type.

Fields of ObjectLifetimeDefault

lifetime: Option<Region>s: &'a Scope<'a>

Supertrait

When we have nested trait refs, we concanetate late bound vars for inner trait refs from outer ones. But we also need to include any HRTB lifetimes encountered when identifying the trait that an associated type is declared on.

Fields of Supertrait

lifetimes: Vec<BoundVariableKind>s: &'a Scope<'a>

TraitRefBoundary

Fields of TraitRefBoundary

s: &'a Scope<'a>

Root

Trait Implementations

impl<'a> Debug for Scope<'a>

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

Size for each variant:

• Binder: 79 bytes
• Body: 23 bytes
• Elision: 47 bytes
• ObjectLifetimeDefault: 31 bytes
• Supertrait: 39 bytes
• TraitRefBoundary: 15 bytes
• Root: 0 bytes