Struct rustc_middle::ty::ClosureArgs

pub struct ClosureArgs<'tcx> {
    pub args: GenericArgsRef<'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

Coroutines

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

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

Fields

args: GenericArgsRef<'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> ClosureArgs<'tcx>

pub fn new( tcx: TyCtxt<'tcx>, parts: ClosureArgsParts<'tcx> ) -> ClosureArgs<'tcx>

Construct ClosureArgs from ClosureArgsParts, containing Args for the closure parent, alongside additional closure-specific components.

fn split(self) -> ClosureArgsParts<'tcx>

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

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

Returns the substitutions of the closure’s parent.

pub fn upvar_tys(self) -> &'tcx List<Ty<'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(args).

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 ClosureArgs<'tcx>

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

Returns a copy of the value.

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

Performs copy-assignment from source.

impl<'tcx> Debug for ClosureArgs<'tcx>

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

Formats the value using the given formatter.

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

type Lifted = ClosureArgs<'__lifted>

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

impl<'tcx> PartialEq for ClosureArgs<'tcx>

fn eq(&self, other: &ClosureArgs<'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 ClosureArgs<'tcx>

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

impl<'tcx> TypeFoldable<TyCtxt<'tcx>> for ClosureArgs<'tcx>

fn try_fold_with<__F: FallibleTypeFolder<TyCtxt<'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>(self, folder: &mut F) -> Self

where F: TypeFolder<I>,

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<TyCtxt<'tcx>> for ClosureArgs<'tcx>

fn visit_with<__V: TypeVisitor<TyCtxt<'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).

impl<'tcx> Copy for ClosureArgs<'tcx>

impl<'tcx> Eq for ClosureArgs<'tcx>

impl<'tcx> StructuralPartialEq for ClosureArgs<'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