Merge #1608

1608: Initial support for closures r=philberty a=philberty

This patch series introduces initial support for closures. Rust's implementation
of closures is actually pretty clever, the function signatures for closures is driven
by the specific FnTrait that the closure implements, this means a CallExpr to a closure
becomes a method-call expr with the receiver type being the closure itself using the
normal autoderef mechanism to do method selection for an implicit impl block.

See https://github.com/rust-lang/rust/blob/7807a694c2f079fd3f395821bcc357eee8650071/library/core/src/ops/function.rs#L54-L71

The other implicit part of this is that arguments being passed to a closure _must_
be passed as a tuple. The down side of allowing libcore to specify the signatures
of the closure functions is that we are limited in how we pass arguments, but
using a tuple and then using similar machinery from the match-expr to restructure
the parameter access to become the tuple accessors makes it look seamless. For
example:

```rust
  let closure_annotated = |i: i32| -> i32 { i + 123 };
  let i = 1;
  closure_annotated(i);
```

Wil generate a function and call-expr such as:

```c
i32 test::main::{{closure}} (struct {{closure}} $closure, struct (i32) args)
{
  _1 = args.__0; // this is 'i'
  return _1 + 123;
}


__attribute__((cdecl))
i32 test::main ()
{
  struct 
{
  i32 __0;
} D.137;
  i32 D.140;
  const i32 a;
  const struct{{closure}} closure_annotated;
  const i32 i;

  try
    {
      a = 1;
      i = 1;
      D.137.__0 = i;
      _1 = test::main::{{closure}} (closure_annotated, D.137);
     <...>
    }
  finally
    {
      closure_annotated = {CLOBBER(eol)};
    }
}

```

Note this patch series does not implement the argument capture yet but this patch set is
good start to the implementation so far. 

Addresses #195 

Co-authored-by: Philip Herron <philip.herron@embecosm.com>

0 files changed, 0 insertions, 0 deletions