-
Notifications
You must be signed in to change notification settings - Fork 9
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
feat: Add shared_fn
macro
#55
Conversation
/// `export_fn` is used to define a function that will be exported by a plugin, but is not directly | ||
/// callable by an Extism runtime. These functions can be used for runtime linking and mocking host | ||
/// functions for tests. If direct access to Wasm native parameters is needed, then a bare | ||
/// `extern "C" fn` should be used 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.
Maybe ass an example of this here
derive/src/lib.rs
Outdated
/// All arguments should implement `extism_pdk::ToBytes` and the return value should implement | ||
/// `extism_pdk::FromBytes` | ||
#[proc_macro_attribute] | ||
pub fn export_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'm a little unsure of name. The docs make it clear. But it's hard to tell which to use just from the name. I can't think of a better name though.
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.
Yea, agreed that although the docs make it clear, the name is a little ambiguous.
What about something like #[linkable_fn]
? That is, a function which can be linked by Extism. I had also thought about #[shared_fn]
, since like a shared library, you don't execute it via a main entrypoint, but through some other execution path some code finds a function and calls it?
I think my main concern is that an Extism user, with even rudimentary knowledge of Wasm is going to see #[export_fn]
and mistake it for #[plugin_fn]
, since the name correctly suggests the function will be exported.
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 like shared_fn
- I will switch it
shared_fn
macro to export functions with non-plugin-function signatures. All arguments will be treated as Extism pointers (u64)extism_pdk::MemoryPointer<T>
as part of the implementation ofexport_fn
. It transparently wrapsu64
, making it possible to use it as an argument when writing export functions without any extism_pdk macros: