-
Notifications
You must be signed in to change notification settings - Fork 355
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
Cosmwasm 0.16 #338
Cosmwasm 0.16 #338
Conversation
Nice.
Agreed. |
Can you rebase this and update to cosmwasm 0.16.0-rc4. That is integrated in wasmd and close enough to final. Happy to have this merged in, so there are no more merge conflicts moving forward |
Besides the missing rebase (see conflicts), I assume this is ready to merge? Can you rebase and pull it out of draft mode and I will give a final review |
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.
Looks good. Two minor comments.
One push for getting this done pre-0.16.0 final is making sure we shape the API with this feedback. Also, some other crates depend on cosmwasm-plus, so if we could make a 0.8.0-rc1, we can get more feedback of use cases when updating those crates.
Usage is the best way to polish off the API.
@@ -170,8 +178,9 @@ pub fn ibc_packet_receive( | |||
attributes: vec![ | |||
attr("action", "receive"), | |||
attr("success", "false"), | |||
attr("error", err), | |||
attr("error", err.to_string()), |
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 know you cannot implement attr for both impl Into<String>
and impl ToString
as some structs implement both and you get a compiler error there.
Is there a way to say K: ToString & !Into<String>
? I think I looked into this some months ago and found it worked in unstable rust (and used to optimise std lib Vec for example)
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.
Seems like this is what I am asking for rust-lang/rfcs#1210
Which is only on nightly (specialization and min_specialization)
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.
Ayep. It's probably just something we have to live with.
Also, explicitly disable it where we're not using it
Rebased and migrated to |
I just want to point out we're removing 250 lines of code in this PR! Ha. |
🔥 |
and the target branch keeps moving.... let's pull this out of draft and rebase again. I will merge when green |
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'd prefer more idiomatic add_attribute usage, even if it does take a bit more time. These are reference contracts
}; | ||
let res = Response::new() | ||
.add_messages(msgs) | ||
.add_attributes(vec![attr("action", "execute"), attr("owner", info.sender)]); |
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.
wouldn't that be simpler with 2 add_attribute calls, since they are different V.
Not to be a stickler, but these contracts are like an example for other devs to follow
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.
Done almost everywhere now. We barely ever use attr
.
attr("owner", info.sender), | ||
attr("spender", spender), | ||
attr("denomination", amount.denom), | ||
attr("amount", amount.amount), |
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.
same here, I'd only use add_attributes when you don't need to use attr
attr("denomination", amount.denom), | ||
attr("amount", amount.amount), | ||
]); | ||
let res = Response::new() |
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.
🚀
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.
Awesome!
@@ -683,7 +682,7 @@ mod tests { | |||
) | |||
.unwrap(); | |||
assert_eq!(0, res.messages.len()); | |||
assert_eq!(attr("action", "create"), res.attributes[0]); | |||
assert_eq!(("action", "create"), res.attributes[0]); |
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.
Good fix as well
attr("action", "execute"), | ||
attr("sender", SOMEBODY), | ||
attr("proposal_id", proposal_id.to_string()), | ||
[ |
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.
Wow, this works over arrays as well? Good stuff.
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.
Oh, yeah. Sometimes if you implement a trait like PartialEq
for type T
, it turns out some generic implementation for [T; 3]
or Vec<T>
or something kicks in from Rust's std
and cool things happen.
Just your run-of-the-mill cosmwasm update.
We should probably hold off with merging this until we have a full release rather than an RC.
Closes #333