Struct rustc_middle::ty::sty::ClosureSubsts

pub struct ClosureSubsts<'tcx> {
    pub substs: SubstsRef<'tcx>,
}

A closure can be modeled as a struct that looks like:

struct Closure<'l0...'li, T0...Tj, CK, CS, U>(...U);

where:

• ’l0…’li and T0…Tj are the generic parameters in scope on the function that defined the closure,
• CK represents the closure kind (Fn vs FnMut vs FnOnce). This is rather hackily encoded via a scalar type. See Ty::to_opt_closure_kind for details.
• CS represents the closure signature, representing as a fn() type. For example, fn(u32, u32) -> u32 would mean that the closure implements CK<(u32, u32), Output = u32>, where CK is the trait specified above.
• U is a type parameter representing the types of its upvars, tupled up (borrowed, if appropriate; that is, if a U field represents a by-ref upvar, and the up-var has the type Foo, then that field of U will be &Foo).

So, for example, given this function:

fn foo<'a, T>(data: &'a mut T) {
     do(|| data.count += 1)
}

the type of the closure would be something like:

struct Closure<'a, T, U>(...U);

Note that the type of the upvar is not specified in the struct. You may wonder how the impl would then be able to use the upvar, if it doesn’t know it’s type? The answer is that the impl is (conceptually) not fully generic over Closure but rather tied to instances with the expected upvar types:

impl<'b, 'a, T> FnMut() for Closure<'a, T, (&'b mut &'a mut T,)> {
    ...
}

You can see that the impl fully specified the type of the upvar and thus knows full well that data has type &'b mut &'a mut T. (Here, I am assuming that data is mut-borrowed.)

Now, the last question you may ask is: Why include the upvar types in an extra type parameter? The reason for this design is that the upvar types can reference lifetimes that are internal to the creating function. In my example above, for example, the lifetime 'b represents the scope of the closure itself; this is some subset of foo, probably just the scope of the call to the to do(). If we just had the lifetime/type parameters from the enclosing function, we couldn’t name this lifetime 'b. Note that there can also be lifetimes in the types of the upvars themselves, if one of them happens to be a reference to something that the creating fn owns.

OK, you say, so why not create a more minimal set of parameters that just includes the extra lifetime parameters? The answer is primarily that it would be hard — we don’t know at the time when we create the closure type what the full types of the upvars are, nor do we know which are borrowed and which are not. In this design, we can just supply a fresh type parameter and figure that out later.

All right, you say, but why include the type parameters from the original function then? The answer is that codegen may need them when monomorphizing, and they may not appear in the upvars. A closure could capture no variables but still make use of some in-scope type parameter with a bound (e.g., if our example above had an extra U: Default, and the closure called U::default()).

There is another reason. This design (implicitly) prohibits closures from capturing themselves (except via a trait object). This simplifies closure inference considerably, since it means that when we infer the kind of a closure or its upvars, we don’t have to handle cycles where the decisions we make for closure C wind up influencing the decisions we ought to make for closure C (which would then require fixed point iteration to handle). Plus it fixes an ICE. :P

Generators

Generators are handled similarly in GeneratorSubsts. The set of type parameters is similar, but CK and CS are replaced by the following type parameters:

• GS: The generator’s “resume type”, which is the type of the argument passed to resume, and the type of yield expressions inside the generator.
• GY: The “yield type”, which is the type of values passed to yield inside the generator.
• GR: The “return type”, which is the type of value returned upon completion of the generator.
• GW: The “generator witness”.

Fields

substs: SubstsRef<'tcx>

Lifetime and type parameters from the enclosing function, concatenated with a tuple containing the types of the upvars.

These are separated out because codegen wants to pass them around when monomorphizing.

Implementations

impl<'tcx> ClosureSubsts<'tcx>

pub fn new(
    tcx: TyCtxt<'tcx>,
    parts: ClosureSubstsParts<'tcx, Ty<'tcx>>
) -> ClosureSubsts<'tcx>

Construct ClosureSubsts from ClosureSubstsParts, containing Substs for the closure parent, alongside additional closure-specific components.

fn split(self) -> ClosureSubstsParts<'tcx, GenericArg<'tcx>>

Divides the closure substs into their respective components. The ordering assumed here must match that used by ClosureSubsts::new above.

pub fn is_valid(self) -> bool

Returns true only if enough of the synthetic types are known to allow using all of the methods on ClosureSubsts without panicking.

Used primarily by ty::print::pretty to be able to handle closure types that haven’t had their synthetic types substituted in.

pub fn parent_substs(self) -> &'tcx [GenericArg<'tcx>]

Returns the substitutions of the closure’s parent.

pub fn upvar_tys(self) -> impl Iterator<Item = Ty<'tcx>> + 'tcx

Returns an iterator over the list of types of captured paths by the closure. In case there was a type error in figuring out the types of the captured path, an empty iterator is returned.

pub fn tupled_upvars_ty(self) -> Ty<'tcx>

Returns the tuple type representing the upvars for this closure.

pub fn kind_ty(self) -> Ty<'tcx>

Returns the closure kind for this closure; may return a type variable during inference. To get the closure kind during inference, use infcx.closure_kind(substs).

pub fn sig_as_fn_ptr_ty(self) -> Ty<'tcx>

Returns the fn pointer type representing the closure signature for this closure.

pub fn kind(self) -> ClosureKind

Returns the closure kind for this closure; only usable outside of an inference context, because in that context we know that there are no type variables.

If you have an inference context, use infcx.closure_kind().

pub fn sig(self) -> PolyFnSig<'tcx>

Extracts the signature from the closure.

pub fn print_as_impl_trait(self) -> PrintClosureAsImpl<'tcx>

Trait Implementations

impl<'tcx> Clone for ClosureSubsts<'tcx>

fn clone(&self) -> ClosureSubsts<'tcx>

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl<'tcx> Debug for ClosureSubsts<'tcx>

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

Formats the value using the given formatter.

impl<'tcx, '__lifted> Lift<'__lifted> for ClosureSubsts<'tcx>

type Lifted = ClosureSubsts<'__lifted>

fn lift_to_tcx(
    self,
    __tcx: TyCtxt<'__lifted>
) -> Option<ClosureSubsts<'__lifted>>

impl<'tcx> PartialEq<ClosureSubsts<'tcx>> for ClosureSubsts<'tcx>

fn eq(&self, other: &ClosureSubsts<'tcx>) -> bool

This method tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

This method tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl<'tcx> Relate<'tcx> for ClosureSubsts<'tcx>

fn relate<R: TypeRelation<'tcx>>(
    relation: &mut R,
    a: ClosureSubsts<'tcx>,
    b: ClosureSubsts<'tcx>
) -> RelateResult<'tcx, ClosureSubsts<'tcx>>

impl<'tcx> TypeFoldable<'tcx> for ClosureSubsts<'tcx>

fn try_fold_with<__F: FallibleTypeFolder<'tcx>>(
    self,
    __folder: &mut __F
) -> Result<Self, __F::Error>

The entry point for folding. To fold a value t with a folder f call: t.try_fold_with(f).

fn fold_with<F: TypeFolder<'tcx>>(self, folder: &mut F) -> Self

A convenient alternative to try_fold_with for use with infallible folders. Do not override this method, to ensure coherence with try_fold_with.

impl<'tcx> TypeVisitable<'tcx> for ClosureSubsts<'tcx>

fn visit_with<__V: TypeVisitor<'tcx>>(
    &self,
    __visitor: &mut __V
) -> ControlFlow<__V::BreakTy>

The entry point for visiting. To visit a value t with a visitor v call: t.visit_with(v).

fn has_vars_bound_at_or_above(&self, binder: DebruijnIndex) -> bool

Returns true if self has any late-bound regions that are either bound by binder or bound by some binder outside of binder. If binder is ty::INNERMOST, this indicates whether there are any late-bound regions that appear free.

fn has_vars_bound_above(&self, binder: DebruijnIndex) -> bool

Returns true if this type has any regions that escape binder (and hence are not bound by it).

fn has_escaping_bound_vars(&self) -> bool

Return true if this type has regions that are not a part of the type. For example, for<'a> fn(&'a i32) return false, while fn(&'a i32) would return true. The latter can occur when traversing through the former.

fn has_type_flags(&self, flags: TypeFlags) -> bool

fn has_projections(&self) -> bool

fn has_opaque_types(&self) -> bool

fn references_error(&self) -> bool

fn error_reported(&self) -> Result<(), ErrorGuaranteed>

fn has_non_region_param(&self) -> bool

fn has_infer_regions(&self) -> bool

fn has_infer_types(&self) -> bool

fn has_non_region_infer(&self) -> bool

fn needs_infer(&self) -> bool

fn has_placeholders(&self) -> bool

fn needs_subst(&self) -> bool

fn has_free_regions(&self) -> bool

“Free” regions in this context means that it has any region that is not (a) erased or (b) late-bound.

fn has_erased_regions(&self) -> bool

fn has_erasable_regions(&self) -> bool

True if there are any un-erased free regions.

fn is_global(&self) -> bool

Indicates whether this value references only ‘global’ generic parameters that are the same regardless of what fn we are in. This is used for caching.

fn has_late_bound_regions(&self) -> bool

True if there are any late-bound regions

fn still_further_specializable(&self) -> bool

Indicates whether this value still has parameters/placeholders/inference variables which could be replaced later, in a way that would change the results of impl specialization.

impl<'tcx> Copy for ClosureSubsts<'tcx>

impl<'tcx> Eq for ClosureSubsts<'tcx>

impl<'tcx> StructuralEq for ClosureSubsts<'tcx>

impl<'tcx> StructuralPartialEq for ClosureSubsts<'tcx>

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