-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support for rust fns #4
Conversation
Marked as draft, since many more tests need to be added. However, actual functionality is complete. |
format!("test {}", input) | ||
} | ||
|
||
#[cfg_attr(feature = "derive", duktape_fn)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find it surprising that this produces two items as the proc macro output. Could the value be transformed into static test_rust_complex_fn: DukFunction = unsafe { DukFunction::new(1, |...| { ... }) }
or something that is actually still one item? Could it be expressed using a trait instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can make it one item, where the function being annotated is replaced with the derived version. This would prevent the fn being usable in a non-duktape scenario however. Is this desired?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess you can still impl<F> Fn for DukFunction<F> where F: Fn
and so on, to make it callable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
implementing Fn is unstable. The solution @samsartor came up with, that I implemented, I think is our best bet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM!
So what I did here was add a module with the same name as the function. Turns out rust allows this, and will decide which to use depending on context. The module exports a struct that implements an unsafe trait called |
I've been slow to respond to this PR, let me know if this is still relevant for you and I will take another pass at the review! |
yes this is still relevant. would be a nice feature to have :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some more comments, mostly concerning soundness, but again I'm happy to merge this if you think this has been taking too long already :)
format!("test {}", input) | ||
} | ||
|
||
#[cfg_attr(feature = "derive", duktape_fn)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM!
alright it's finally time to start using this. if we can get it merged, that would be cool. if not, I can just publish and maintain a fork |
alright, pretty sure all comments are addressed |
Adds a serde backend for duktape that allows for serializing rust types onto the stack, and deserializing them off of the stack.
Adds an attribute macro
duktape_fn
which can be applied to a rust function which will generate a wrapper function that can be imported into a duktape context. All arguments must implementserde::Deserialize
and the return type must implementserde::Serialize
.Adds a function-like macro
add_global_fn!
which takes a context and a function that has theduktape_fn
attribute, and adds it to the global object.