Skip to content
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

Update cosmwasm-std #260

Merged
merged 92 commits into from
Apr 13, 2021
Merged

Update cosmwasm-std #260

merged 92 commits into from
Apr 13, 2021

Conversation

yihuang
Copy link
Contributor

@yihuang yihuang commented Apr 2, 2021

Maybe merge after the cosmwasm-std version released.

@yihuang yihuang marked this pull request as draft April 2, 2021 02:15
@ethanfrey
Copy link
Member

Thanks for this initiative. There are a few more changes, and let's wait til a 0.14.0-beta2 is out to finalize this.

@ethanfrey
Copy link
Member

https://github.com/CosmWasm/cosmwasm/releases/tag/v0.14.0-beta2 is now out (inspired by your work to cut this now).

No pressure, but feel free to upgrade to that and I'd be happy to merge.
Only remaining (major) plans for 0.14.0 is some refactoring of the IBC bindings, but everything else should be pretty stable now.

@yihuang
Copy link
Contributor Author

yihuang commented Apr 8, 2021

https://github.com/CosmWasm/cosmwasm/releases/tag/v0.14.0-beta2 is now out (inspired by your work to cut this now).

No pressure, but feel free to upgrade to that and I'd be happy to merge.
Only remaining (major) plans for 0.14.0 is some refactoring of the IBC bindings, but everything else should be pretty stable now.

There are many changes needed in multi-test for recent address change, I'm not sure when to use Addr::unchecked or addr_validate.

@maurolacy
Copy link
Contributor

maurolacy commented Apr 8, 2021

There are many changes needed in multi-test for recent address change, I'm not sure when to use Addr::unchecked or addr_validate.

This comment https://github.com/CosmWasm/cosmwasm/blob/main/packages/std/src/addresses.rs#L30:L44 may be of help.

@yihuang
Copy link
Contributor Author

yihuang commented Apr 8, 2021

There are many changes needed in multi-test for recent address change, I'm not sure when to use Addr::unchecked or addr_validate.

This comment https://github.com/CosmWasm/cosmwasm/blob/main/packages/std/src/addresses.rs#L30:L44 may be of help.

Since multi-test is a test library, i suppose it's free to use Addr:unchecked as needed?

@maurolacy
Copy link
Contributor

maurolacy commented Apr 8, 2021

There are many changes needed in multi-test for recent address change, I'm not sure when to use Addr::unchecked or addr_validate.

This comment https://github.com/CosmWasm/cosmwasm/blob/main/packages/std/src/addresses.rs#L30:L44 may be of help.

Since multi-test is a test library, i suppose it's free to use Addr:unchecked as needed?

I guess it depends on the particular case. Basically, use Addr::unchecked to generate a dummy Addr from a string in test code. Or an Addr in contract code, if it has already been validated. For the other cases, you should use addr_validate() to generate an Addr from a string. Or addr_humanize(), to generate an Addr from a (binary repr) CanonicalAddr.

If you post a specific example / instance, we can discuss it.

@maurolacy
Copy link
Contributor

maurolacy commented Apr 8, 2021

On second thought, I think you're right. If we want the multi-test framework to work generically over addresses, unchecked would be the right choice.

@ethanfrey
Copy link
Member

I just merged in your cw1155 contract. Many thanks for that.

If you want to rebase and push with latest master and v0.14.0-beta2, I will look at the compile failures in multi-test and maybe can fix them (or at least find a good solution). multi-test is kind of my baby and in beta.

@ethanfrey
Copy link
Member

My short feedback is in non-test code s/HumanAddr/Addr/ and if we really need to create them, we look at it (and avoid unchecked if possible).

In test code, HumanAddr::from("owner") -> Addr::unchecked("owner")

@yihuang
Copy link
Contributor Author

yihuang commented Apr 8, 2021

@ethanfrey @maurolacy I pushed lots of address related changes, it's not complete yet, I guess you can check it out now to see if I'm on the right track 😄

@ethanfrey
Copy link
Member

Thank you, I will look

Copy link
Member

@ethanfrey ethanfrey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took a brief look at multi-test.

I added some comments, but I am not sure if I am just making a huge pile of work here. Let's go with your approach using Addr::unchecked as needed here and I can always do another PR later to add validation. Multi-test is only test code, so this is more pedantic.

I will look at the contracts to see use in production code.

match msg {
WasmMsg::Execute {
contract_addr,
msg,
send,
} => {
let contract_addr = Addr::unchecked(contract_addr);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would validate here instead of unchecked.

let contract_addr = self.api.addr_validate(&contract_addr)?; should work here, well, except for the String error.

Maybe add App.add_validate(addr: &str) -> Result<Addr, String> which is a small wrapper around the above, then we can use that where needed in production code.

@@ -381,9 +378,9 @@ where
send,
label: _,
} => {
let contract_addr = self.wasm.register_contract(code_id as usize)?;
let contract_addr = Addr::unchecked(self.wasm.register_contract(code_id as usize)?);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

register_contract should return Addr.

Copy link
Member

@ethanfrey ethanfrey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some feedback.

This is hard to get right, and I only understood the proper usage after discussing with Simon on the PR. We need to update the migration / readme - any suggestions are welcome.

Basically, anything that can be set by external users should be String. This includes anything entering and leaving the contract (query response is parsed by someone else and will not trust the contract by default).

Anything we save to state should be Addr, to ensure it is valid.

We can remove almost all usage of CanonicalAddr. You can keep them for keys (like maybe_canonical), but I may replace that with Addr in the keys in the future.

}

// this will set the first key after the provided key, by appending a 0 byte
pub fn calc_range_start_human(
api: &dyn Api,
start_after: Option<HumanAddr>,
start_after: Option<Addr>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is used anywhere anymore. It can be removed.

/// for working with this.
///
/// If you wish to persist this, convert to Cw1CanonicalContract via .canonical()
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct Cw1Contract(pub HumanAddr);
pub struct Cw1Contract(pub Addr);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@@ -42,7 +42,7 @@ pub struct Cw1CanonicalContract(pub CanonicalAddr);
impl Cw1CanonicalContract {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can remove this entirely, as I we are moving away from CanonicalContracts.

Fine if you leave this for now to make the PR smaller, and I can take a second PR for that one.

@@ -44,7 +42,7 @@ pub fn set_contract_version<T: Into<String>, U: Into<String>>(
/// if the other contract exists and claims to be a cw20-base contract for example.
/// (Note: you usually want to require *interfaces* not *implementations* of the
/// contracts you compose with, so be careful of overuse)
pub fn query_contract_info<Q: Querier, T: Into<HumanAddr>>(
pub fn query_contract_info<Q: Querier, T: Into<String>>(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Into<String> 👍

@@ -31,20 +31,20 @@ pub enum Cw3QueryMsg {
/// Query the vote made by the given voter on `proposal_id`. This should
/// return an error if there is no such proposal. It will return a None value
/// if the proposal exists but the voter did not vote. Returns VoteResponse
Vote { proposal_id: u64, voter: HumanAddr },
Vote { proposal_id: u64, voter: Addr },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All *Msg types should use String (this is unverified input from users)
All state should use Addr.

By doing so, the compiler should enforce we validate input before saving it

@@ -168,7 +168,7 @@ pub struct VoteListResponse {
/// the address of the voter who submitted it
#[derive(Serialize, Deserialize, Clone, PartialEq, JsonSchema, Debug)]
pub struct VoteInfo {
pub voter: HumanAddr,
pub voter: Addr,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again String here

old_weight: Option<u64>,
new_weight: Option<u64>,
) -> Self {
pub fn new<T: Into<Addr>>(addr: T, old_weight: Option<u64>, new_weight: Option<u64>) -> Self {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there anything that really implements Into<Addr>? I think we can just use Addr here (or does this allow &addr as well as addr as args?)

@@ -53,10 +49,10 @@ impl MemberChangedHookMsg {
}

/// creates a cosmos_msg sending this struct to the named contract
pub fn into_cosmos_msg(self, contract_addr: HumanAddr) -> StdResult<CosmosMsg> {
pub fn into_cosmos_msg(self, contract_addr: Addr) -> StdResult<CosmosMsg> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe Into<String> here? So we can use Addr, String, or &str?

@@ -10,17 +10,13 @@ use cosmwasm_std::{to_binary, Binary, CosmosMsg, HumanAddr, StdResult, WasmMsg};
/// old = Some, new = None -> Delete
#[derive(Serialize, Deserialize, Clone, PartialEq, JsonSchema, Debug)]
pub struct MemberDiff {
pub key: HumanAddr,
pub key: Addr,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, this is a message, not state.
Again, use String.
Addr only in state and env/info from the runtime (already trusted)

@ethanfrey
Copy link
Member

This may be easier to collaborate if you could make a branch on this repo, so I would push some code and collaborate on this PR (this is a huge cleanup task we don't need to dump entirely on you, but thank you very much for taking it on).
Do you want write access to this repo?

@yihuang
Copy link
Contributor Author

yihuang commented Apr 8, 2021

This may be easier to collaborate if you could make a branch on this repo, so I would push some code and collaborate on this PR (this is a huge cleanup task we don't need to dump entirely on you, but thank you very much for taking it on).
Do you want write access to this repo?

I've enabled the option Allow edits by maintainers, I think you can already push to my branch?

@ethanfrey
Copy link
Member

Okay, I will try that and do a quick Addr -> String in the messages.

@ethanfrey
Copy link
Member

Okay, I just pushed a commit for cw1-4 to show what I mean. I am off for lunch for an hour or so.

If this makes sense, feel free to continue. If not, I can pick this up later today

@maurolacy
Copy link
Contributor

@yihuang , can you take it from here and implement the needed changes (add schema) for cw1155-base to pass CI?

@maurolacy
Copy link
Contributor

maurolacy commented Apr 12, 2021

Besides, I think this will require at least a quick review before merging, to try and spot any errors / omissions.

@ethanfrey
Copy link
Member

ethanfrey commented Apr 12, 2021

Besides, I think this will require at least a quick review before merging, to try and spot any errors / omissions.

I will do a review on everything but cw1155 for now, and that when @yihuang flags it as ready.
Thanks for doing all this work @maurolacy

@ethanfrey ethanfrey marked this pull request as ready for review April 12, 2021 18:49
@yihuang
Copy link
Contributor Author

yihuang commented Apr 13, 2021

@yihuang , can you take it from here and implement the needed changes (add schema) for cw1155-base to pass CI?

it seems has done by @ethanfrey ? 👍

@maurolacy
Copy link
Contributor

@yihuang , can you take it from here and implement the needed changes (add schema) for cw1155-base to pass CI?

it seems has done by @ethanfrey ? +1

Yes. We wanted to see the CI solid green. :-)

@ethanfrey
Copy link
Member

I'm pulling out all AddrRef to &Addr before merging. Otherwise, looking good

@ethanfrey ethanfrey merged commit 4099566 into CosmWasm:master Apr 13, 2021
@webmaster128
Copy link
Member

🎉

@ethanfrey
Copy link
Member

Bumping to beta3 in a new PR now. #269

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants