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

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

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

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

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.

Returns the substitutions of the closure’s parent.

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.

Returns the tuple type representing the upvars for this closure.

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).

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

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().

Extracts the signature from the closure.

Trait Implementations

Returns a copy of the value. Read more
Performs copy-assignment from source. Read more
Formats the value using the given formatter. Read more
The entry point for folding. To fold a value t with a folder f call: t.try_fold_with(f). Read more
A convenient alternative to try_fold_with for use with infallible folders. Do not override this method, to ensure coherence with try_fold_with. Read more
The entry point for visiting. To visit a value t with a visitor v call: t.visit_with(v). Read more
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. Read more
Returns true if this self has any regions that escape binder (and hence are not bound by it). Read more
“Free” regions in this context means that it has any region that is not (a) erased or (b) late-bound. Read more
True if there are any un-erased free regions.
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. Read more
True if there are any late-bound regions
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. Read more

Auto Trait Implementations

Blanket Implementations

Gets the TypeId of self. Read more
Immutably borrows from an owned value. Read more
Mutably borrows from an owned value. Read more

Returns the argument unchanged.

Calls U::from(self).

That is, this conversion is whatever the implementation of From<T> for U chooses to do.

The resulting type after obtaining ownership.
Creates owned data from borrowed data, usually by cloning. Read more
Uses borrowed data to replace owned data, usually by cloning. Read more
The type returned in the event of a conversion error.
Performs the conversion.
The type returned in the event of a conversion error.
Performs the conversion.

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