Add #[entry_point] macro attribute to generate entry points

[webmaster128]

Closes #698

Generated code before

via cosmwasm_std::create_entry_points!(contract):

mod wasm {
    use super::contract;
    use cosmwasm_std::{do_handle, do_init, do_migrate, do_query};
    #[no_mangle]
    extern "C" fn init(env_ptr: u32, info_ptr: u32, msg_ptr: u32) -> u32 {
        do_init(&contract::init, env_ptr, info_ptr, msg_ptr)
    }
    #[no_mangle]
    extern "C" fn handle(env_ptr: u32, info_ptr: u32, msg_ptr: u32) -> u32 {
        do_handle(&contract::handle, env_ptr, info_ptr, msg_ptr)
    }
    #[no_mangle]
    extern "C" fn query(env_ptr: u32, msg_ptr: u32) -> u32 {
        do_query(&contract::query, env_ptr, msg_ptr)
    }
}

Generated code after

Via #[entry_point]:

    #[cfg(target_arch = "wasm32")]
    mod __wasm_export_init {
        #[no_mangle]
        extern "C" fn init(ptr0: u32, ptr1: u32, ptr2: u32) -> u32 {
            cosmwasm_std::do_init(&super::init, ptr0, ptr1, ptr2)
        }
    }

    // ...

    #[cfg(target_arch = "wasm32")]
    mod __wasm_export_handle {
        #[no_mangle]
        extern "C" fn handle(ptr0: u32, ptr1: u32, ptr2: u32) -> u32 {
            cosmwasm_std::do_handle(&super::handle, ptr0, ptr1, ptr2)
        }
    }

    // ...
    
    #[cfg(target_arch = "wasm32")]
    mod __wasm_export_query {
        #[no_mangle]
        extern "C" fn query(ptr0: u32, ptr1: u32) -> u32 {
            cosmwasm_std::do_query(&super::query, ptr0, ptr1)
        }
    }

[ethanfrey]

Nice, I will review Monday.

My first comment is that
#[cfg(target_arch = "wasm32")] is now hard coded.

In cosmwasm-plus we sometimes import code from one contract to use in another. And to do so, we also gate entry points on a library feature flag as well.

See example here https://github.com/CosmWasm/cosmwasm-plus/blob/master/contracts/cw20-base/src/lib.rs#L12

Can you either use the same feature flags as that example, or allow the app developer to do so... the init function should always be present, but the export suppressed if we set the library flag

[ethanfrey]

Nice we can use the same entry point macro on all the different functions. This does make it cleaner.

[webmaster128]

Can you either use the same feature flags as that example, or allow the app developer to do so... the init function should always be present, but the export suppressed if we set the library flag

The entry_point macro attribute can be added conditionally, like this:

#[cfg_attr(not(feature = "library"), entry_point)]
pub fn init(
    mut deps: DepsMut,
    _env: Env,
    _info: MessageInfo,
    msg: InitMsg,
) -> StdResult<InitResponse> {

I tested this here: CosmWasm/cw-plus#216. The wasm32 check remains internal. I.e. entry_point exists but it a noop on non-wasm targets.

[ethanfrey]

I added #704 to provide a demo solution to my cosmwasm-plus question. If you have a better solution (eg. #[entry_point] and #[entry_point(library)] or always using the library feature flag in the generated macro, I am happy for that as well.

But let's document how to do this properly for cosmwasm-plus.

NB: I tried #[cfg_attr(not(feature = "bibliothek"), entry_point)] on a crate with the library feature (and no bibliothek feature) and it compiled fine and created the entry point. Maybe just use this in the macro code:

        r##"
        #[cfg(all(target_arch = "wasm32", not(feature = "library")))]
        mod __wasm_export_{name} {{ // new module to avoid conflict of function name

And just document that you can use a "library" feature (if added to the contract's Cargo.toml) to disable entry point generation in wasm

[ethanfrey]

nice way to check the entry points

[ethanfrey]

I guess if there wasn't such super power, then you could just simplify the doc tests. But cool this works

[webmaster128]

One thing we can always do is not not compile an example in the documentation tests, like here:

/// # Example
///
/// ```ignore
/// use contract; // The contract module
///
/// cosmwasm_std::create_entry_points!(contract);
/// ```

However, this disables automatic doc testing for the block and makes it easy to forget when updating code.

[ethanfrey]

This is ptr0,ptr1,ptr2 without spaces. I would add a space after the comma (in both) or change the comments

[webmaster128]

Well spotted. I did not see this because the code is automatically formatted when using cargo expand.

[ethanfrey]

Looking at

cosmwasm/packages/std/src/exports.rs

Lines 96 to 115 in b38e790

	pub fn do_handle<M, C, E>(
	handle_fn: &dyn Fn(DepsMut, Env, MessageInfo, M) -> Result<HandleResponse<C>, E>,
	env_ptr: u32,
	info_ptr: u32,
	msg_ptr: u32,
	) -> u32
	where
	M: DeserializeOwned + JsonSchema,
	C: Serialize + Clone + fmt::Debug + PartialEq + JsonSchema,
	E: ToString,
	{
	let res = _do_handle(
	handle_fn,
	env_ptr as *mut Region,
	info_ptr as *mut Region,
	msg_ptr as *mut Region,
	);
	let v = to_vec(&res).unwrap();
	release_buffer(v) as u32
	}

I wonder if this do_{name} code could be auto-generated.

We have the concrete type info from the function we are decorating, the rest is mostly boilerplate.

(I would do that as a separate PR however)

[webmaster128]

Jupp, much to explore from here.

I also though about Multi-value regions in #602, such that we can have always have one pointer input and one pointer output.

[ethanfrey]

I also though about Multi-value regions in #602, such that we can have always have one pointer input and one pointer output.

I think that would actually make the auto-generation harder, as you are accepting a variable number of input slices and then mapping them to a fixed number of typed variables.

But yeah, plenty of room to explore here :)

[ethanfrey]

Huh, i just saw this comment: #701 (comment) after my other PR. Everytime I click on notifications for the diffs, It just showed me "files are missing" and not the new comments (which I missed).

Thanks for that, and let's keep working on this entry_point logic in std, knowing that is can used in cosmwasm-plus

[ethanfrey]

From my end, happy to see it merged, and another pr or two to extend it. But the foundation is there and looks nice

[webmaster128]

From my end, happy to see it merged, and another pr or two to extend it. But the foundation is there and looks nice

Thanks. I think so too. Let me just add the missing spaces of the ptr arguments and then merge.