You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of #186, closures are implemented by letting the consumer of llbc track which function pointer goes with which closure, and the Call terminator mentions a built-in trait implementation for Fn/FnMut/FnOnce that the consumer of llbc must deduce corresponds to the aforementioned function pointer.
I propose that we instead encode this:
pubfntest_closure_capture(x:u32,y:u32) -> u32{let f = &|z| x + y + z;(f)(0)}
This is pretty much exactly how rustc represents closures internally, and has the benefit that consumers of llbc don't need to do anything special to support closures.
The text was updated successfully, but these errors were encountered:
Small update: after a discussion I think we came up with a different solution, where the function pointer is not stored in the state but in the instance of Fn<(u32,)> (maybe it is actually what you mean above, but it is slightly unclear).
That is indeed what I meant above; as you can see, there is no function pointer stored anywhere in the desugared output; the special closure type is just the name for a struct.
As of #186, closures are implemented by letting the consumer of llbc track which function pointer goes with which closure, and the
Call
terminator mentions a built-in trait implementation forFn
/FnMut
/FnOnce
that the consumer of llbc must deduce corresponds to the aforementioned function pointer.I propose that we instead encode this:
as follows:
This is pretty much exactly how rustc represents closures internally, and has the benefit that consumers of llbc don't need to do anything special to support closures.
The text was updated successfully, but these errors were encountered: