Struct rustc_middle::ty::sty::ClosureSubsts [−][src]
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
TyS::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 implementsCK<(u32, u32), Output = u32>
, whereCK
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 toresume
, and the type ofyield
expressions inside the generator.GY
: The “yield type”, which is the type of values passed toyield
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
pub fn new(
tcx: TyCtxt<'tcx>,
parts: ClosureSubstsParts<'tcx, Ty<'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.
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()
.
Trait Implementations
type Lifted = ClosureSubsts<'tcx>
fn relate<R: TypeRelation<'tcx>>(
relation: &mut R,
a: ClosureSubsts<'tcx>,
b: ClosureSubsts<'tcx>
) -> RelateResult<'tcx, ClosureSubsts<'tcx>>
fn super_visit_with<__F: TypeVisitor<'tcx>>(
&self,
__folder: &mut __F
) -> ControlFlow<__F::BreakTy>
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 definitely references only ‘global’ generic parameters that are the same regardless of what fn we are in. This is used for caching. Read more
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
impl<'tcx> !RefUnwindSafe for ClosureSubsts<'tcx>
impl<'tcx> !Send for ClosureSubsts<'tcx>
impl<'tcx> !Sync for ClosureSubsts<'tcx>
impl<'tcx> Unpin for ClosureSubsts<'tcx>
impl<'tcx> !UnwindSafe for ClosureSubsts<'tcx>
Blanket Implementations
Mutably borrows from an owned value. Read more
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