Sylvia 1.2.1

We are happy to announce the 1.2.1 release of the Sylvia framework.

This release does not introduce any new major features but rather improvements in the API.

What’s new in Sylvia 1.2.1

Refactoring Entry Points in the Contract Definition

In the recent release, the handling of generics in the entry_points macro underwent a refactoring to simplify and streamline the attribute syntax.

Previously, the entry_points macro required the user to explicitly specify concrete types used in place of generic custom types with the
, custom(msg=.., query=..) parameter. This caused redundancy as the same types had to be passed to generics<...> parameter.

Since version 1.2.0, Sylvia can deduce which concrete type passed to the generics<..> parameter is a custom type and the , custom() parameter is deprecated.

-#[entry_points(generics<Empty, Empty>, custom(msg=Empty, query=Empty))]
+#[entry_points(generics<Empty, Empty>)]
#[contract]
#[sv::custom(msg=E, query=Q)]
impl<E, Q> Contract<E, Q>
where
    E: CustomMsg + 'static,
    Q: CustomQuery + 'static,
{
}

Emit error if contract macro is above entry_points

Because the contract macro removes all of the Sylvia attributes, it should be placed below the entry_points macro so that the contract macro is called last.

Unfortunately, the compiler errors were not very helpful, so we decided to detect the wrong order of the macros and provide a hint leading directly to the problem:

error: Missing instantiation message.

         = note: `sylvia::entry_points` requires exactly one method marked with `#[sv::msg(instantiation)]` attribute.
         = note: Make sure you implemented the `entry_points` macro above the `contract` macro.

  --> tests/ui/macros/entry_points.rs:69:5
   |
69 |     #[entry_points]
   |     ^^^^^^^^^^^^^^^
   |
   = note: this error originates in the attribute macro `entry_points` (in Nightly builds, run with -Z macro-backtrace for more info)

Add CustomMsg and CustomQuery to ContractApi

Although the ContractApi is mainly intended for use by Sylvia macros, users can now access custom types defined on the contract through it:

// Generated implementation
impl sylvia::types::ContractApi for Contract {
    ...
    type CustomMsg = SvCustomMsg;
    type CustomQuery = SvCustomQuery;
}
// Usage of assigned types
let _: <Contract as ContractApi>::CustomMsg = SvCustomMsg {};
let _: <Contract as ContractApi>::CustomQuery = SvCustomQuery {};

Fix: Forward attributes to struct fields

Forwarding attributes to message fields worked for the enum messages like ExecMsg or QueryMsg but not for the InstantiateMsg and MigrateMsg.
Since 1.2.1 below is possible:

#[sv::msg(instantiate)]
pub fn instantiate(
    &self,
    _ctx: InstantiateCtx,
    #[serde(default)] _desc: String,No
) -> StdResult<Response> {
    Ok(Response::new())
}

The #[serde(default)] attribute would be forwarded to the structure field generated out of the _desc argument:

pub struct InstantiateMsg {
    #[serde(default)]
    pub _desc: String,
}

Other changes

Deprecate InterfaceApi in favor of InterfaceMessagesApi

Since 2.0.0, the InterfaceApi will be removed from Sylvia.
The generated InterfaceMessagesApi serves the same purpose, but instead of containing all of the generics defined on the interface it’s generic over the contract type.

// Construct using dynamic dispatch
let msg = <dyn Interface<
    ExecC = SvCustomMsg,
    QueryC = SvCustomQuery,
    Error = (),
> as sv::InterfaceMessagesApi>::Query::admin_list();

// Construct using contract type
let _ =
    <Contract<SvCustomMsg, SvCustomQuery> as sv::InterfaceMessagesApi>::Query::admin_list();

Update examples to use generic custom messages and queries

Making contracts and interfaces use generic custom types is a good way to give other users the flexibility to reuse your code. The Sylvia examples were updated to showcase this.

Summary

The 1.2.1 release brings multiple minor improvements that set a good direction for the development of the framework.

It is also preceded by work on new documentation that we will be very happy to share with you soon!

With this release we had to yank the 1.2.0 as it was a non-semver complaint due to the removal of support for , custom() in the entry_points macro and removal of the InterfaceApi.
The 1.2.1 is compatible with the previous version.

We are very excited to continue working on the Sylvia framework. Stay tuned, as future versions will include features such as semantic support for reply, migrate, and IBC.

You can learn about the changes in the CHANGELOG and the MIGRATING.