-
Notifications
You must be signed in to change notification settings - Fork 219
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(dan): basic template macro #4358
feat(dan): basic template macro #4358
Conversation
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.
A perfect start!
We can look avoiding the template! {... }
wrapper in another PR.
|
||
use common::{generate_abi, generate_main, TemplateImpl}; | ||
use tari_template_abi::{encode_with_len, FunctionDef, Type}; | ||
template! { |
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.
The scoping is why we'll need to put something like
#[tari::contract]
mod hello_world {
pub struct HelloWorld { etc.}
}
If we want to avoid wrapping in template! {...}
, unless there's another way to get the scoping (I can't think of any) - the main reason is that code completion on some editors breaks when wrapped in declarative macros.
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.
This is fine IMO
It also allows some flexibility, because you can also write your contract in my_contract.rs
, and then in lib.rs
have
#[tari::contract]
mod my_contract;
Looks great. Why is it all in a tests folder though? |
Yeah, let's move the macro out of EDIT: on second thoughts, I want to prevent conflicts with #4350 since I already moved out the "common" crate that was in tests in that PR. Let's make things easy and merge this one and move it out later |
Description --- * Function parameters are correctly encoded and passed to the user function * Component parameters (i.e. `self`) are transparently handled to the user code: 1. The ABI specifies a `u32` type component id 2. The state is retrieved from the engine with that component id (not the real call yet, as it's not implemented in the engine) 3. The state is decoded and passed to the function on the `self` parameter 4. If the attribute is mutable (`&mut self`) then we call the engine to update the component state * Unit return types (`()`) are now supported in functions (see the `State.set` function as an example) * Expanded the `ast.rs` module with convenient functions to detect `self` and constructor functions Motivation and Context --- Following the previous work on the template macro (#4358, #4361), this PR aims to solve some of the previous limitations: * The function arguments must be processed and encoded * Struct fields and `self` must be handled * Calls to the tari engine import should be done instead of mocked With those implemented, the `state` test example is now written as: ``` use tari_template_macros::template; #[template] mod state_template { pub struct State { pub value: u32, } impl State { pub fn new() -> Self { Self { value: 0 } } pub fn set(&mut self, value: u32) { self.value = value; } pub fn get(&self) -> u32 { self.value } } } ``` Please keep in mind that this is the simplest example that manages the contract state, but it currently supports function logic as complex as the user wants, as long as it is valid Rust code. Also, for now I didn't find necessary to mark constructor functions in any special way. Right now, a function is automatically considered a constructor (and the component instantiated) if it returns `Self`. Lastly, as the state managing itself is not yet implemented on the engine, state is not conserved between calls. But this PR encapsulates component related logic in a single module (`component.rs`) so it should be relatively simple to implement in the future. How Has This Been Tested? --- The unit test for the `state` example, now rewritten using the template macro, pass
Description
ast
module.tari_engine
import signature.self
is not handled yetMotivation and Context
Template developers need an ergonomic way of writing contract code. This PR aims to provide a new macro
template!
to allow easy development of new basic contracts. And for basic I mean no struct fields, no resource access and no composability, only stateless functions. Those features will be added in future PRs.With this PR, the existing "Hello World" example is rewritten as:
How Has This Been Tested?