Closure types

[philberty]

https://doc.rust-lang.org/reference/types/closure.html
https://doc.rust-lang.org/rust-by-example/fn/closures.html
https://doc.rust-lang.org/nomicon/hrtb.html

I think there is stuff in GCC we can take inspiration from the C++ implementation of closures for example:

int test() {
    int capture = 456;
    auto a = [&](int a) -> int {
        return a + capture;
    };
    return a(123);
}

will give us

int test ()
{
  int D.2400;
  int capture;
  struct ._anon_0 a;
  typedef struct ._anon_0 ._anon_0;

  try
    {
      capture = 456;
      a.__capture = &capture;
      D.2400 = test()::<lambda(int)>::operator() (&a, 123);
      return D.2400;
    }
  finally
    {
      capture = {CLOBBER};
      a = {CLOBBER};
    }
}

int test()::<lambda(int)>::operator() (const struct ._anon_0 * const __closure, int a)
{
  int D.2403;
  int & capture [value-expr: __closure->__capture];

  _1 = __closure->__capture;
  _2 = *_1;
  D.2403 = a + _2;
  return D.2403;
}

The task list breaks down into:

• Implement ClosureType for the type system
• name resolution to mark captured variables
• backend code generation to generate implicit struct for this closure type and take references, all with must me TREE_ADDRESSABLE
• generate new function body and take code address of it into the lamba implicit struct
• Support function lang-items https://github.com/rust-lang/rust/blob/7807a694c2f079fd3f395821bcc357eee8650071/library/core/src/ops/function.rs#L54-L71
• Investigate blocking unstable stuff in rustc Tracking issue for Fn traits (unboxed_closures & fn_traits feature) rust-lang/rust#29625
• rust-abi will convert variable number of arguments into a tuple

I am currently blocked on this until we get lang-item support into the compiler from my operator overloading branch,

[bjorn3]

Closures are interesting. They get a separate MIR body and DefId in rustc, but typechecking handles them as part of the parent function.

[philberty]

Useful comment from @dkm #523 (comment)

[bjorn3]

Maybe similar to the GNU extension for nested function in C https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

No, nested functions in C require the stack to be executable to put a trampoline. In addition such nested functions are not allowed to escape the current stack frame. In Rust closures are conceptually implemented like the following:

fn foo() {
    let a = 0;
    let b = || a;
    b();
}

// -->

fn foo() {
    struct MyClosure<'a> {
        a: &i32,
    }
    impl<'a> Fn<()> for MyClosure<'a> {
        type Output = i32;
        extern "rust-call" fn call(&self, args: ()) -> i32 {
            *self.a
        }
    }
    let a = 0;
    let b = MyClosure { a: &a };
    b();
}

The "rust-call" abi here is a workaround for the lack of variadic generics in rust. It is basically equivalent to the default "Rust" abi except that the last argument must be a tuple and this tuple will be passed as if every element was listed as argument individually. So eg "extern "rust-call" fn foo(&self, args: (i32, i64)) is equivalent to fn foo(&self, arg1: i32, arg2: i64).

[dkm]

Not sure the requirement for executable stack still holds for all targets as described in https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html

What do you mean by "not allowed to escape current stack frame"? I think you can take a pointer to the nested function and use it in a function call, also shown in the previous link :

hack (int *array, int size)
{
  void store (int index, int value)
    { array[index] = value; }

  intermediate (store, size);
}

Maybe I don't understand your point?

[bjorn3]

For example

fn foo() -> impl FnMut() -> i32 {
    let mut bar = 0;
    move || { bar += 1; bar }
}

is valid. bar gets moved into the closure and then the closure gets returned. The closure escapes the foo function.

[philberty]

Yeah this kind of thing is supported in C++ with std::function and in go. It will be interesting to disect the implementation used from those

[dkm]

For example

fn foo() -> impl FnMut() -> i32 {
    let mut bar = 0;
    move || { bar += 1; bar }
}

is valid. bar gets moved into the closure and then the closure gets returned. The closure escapes the foo function.

Ok, the closure can be used even after the enclosing function has exited, didn't know that...

[philberty]

I could be wrong but i remember reading about go and from my experience with go when you define a closure, it seemed to take a copy of any enclosed names at that time and make them implicit parameters to that closure when it is defined. It caused a few subtle bugs in the product I was working on.

[bjorn3]

If you don't use move Rust will take references to all captured variables. If you do use move all captured variables are moved into the closure and inaccessible outside if they are not Copy.

Yeah this kind of thing is supported in C++ with std::function and in go. It will be interesting to disect the implementation used from those

Unlike in Rust these have to use heap allocation I think to store all captures. In Rust every closure has a distinct type with a size depending on the captured variables. In addition if all captured variables implement Copy, so does the closure. Same for Clone.

[philberty]

This is a useful testcase from rust-lang/rust#45510:

#![feature(fn_traits)] 
#![feature(unboxed_closures)]

struct Ishmael;
struct Maybe;
struct CallMe;

impl FnOnce<(Ishmael,)> for CallMe {
    type Output = ();
    extern "rust-call" fn call_once(self, _args: (Ishmael,)) -> () {
        println!("Split your lungs with blood and thunder!");
    }
}

impl FnOnce<(Maybe,)> for CallMe {
    type Output = ();
    extern "rust-call" fn call_once(self, _args: (Maybe,)) -> () {
        println!("So we just met, and this is crazy");
    }
}

fn main() {
    CallMe(Ishmael);
    CallMe(Maybe);
}