no_std support for cosmwasm-std

[aeryz]

Added no_std support to cosmwasm-std so that no_std projects can use it like our cosmwasm-vm. Note that it doesn't change anything when it compiles for std and since std is added to the default features, none of existing users of cosmwasm-std will be effected.

[dzmitry-lahoda]

would this help to have follow up changes, for example cw-storage-plus?

[webmaster128]

Great work, thanks a lot.

I'm pretty impressed by your work re-implementing cosmwasm-vm. Congratz and respect. As mentioned in #1484 this is a valuable step to ensure the codebases converge instead of diverge. The diff might look big to some people, but I think it is tiny compared to a cosmwasm-std copy. Looking forward to see your team contributing to the main codebase!

I have a few comments inline. Some follow-up items are

• Add no_std CI jobs (at least build and unit test of cosmwasm-std)
• Add CHANGELOG entry

[aeryz]

@webmaster128 Hi Simon, thank you for your kind words! I thought that serde_json_wasm was no_std but sadly it is not. It is weird that no_std builds compile successfully. It only fails when you have a target like thumbv7m-none-eabi. Hence, we thought about dividing std into two parts:

• std-base: common types that are used by the VM and contracts. This will have no_std feature.
• std: std implementation and other types (if any). This will only be std.

This will make it easier to maintain functionality of std. std won't necessarily need to be restricted with no_std and it would make it much more easier to use a crate that doesn't support no_std (like serde_json_wasm, thiserror, etc.).

[webmaster128]

Would you guys mind copying over the relevant parts of the mininal package discussion to #1484 such that we have continue the design discussion there? Feels like we are about to close here soon.

[aeryz]

Hey @webmaster128, I realized that splitting this will bring too many changes as well as some breaking ones. So it is best to stick with a single std imo. So I updated this PR to build for both std and no_std without an issue. Few notable parts are:

• std feature is used instead of no_std to be able to enable optional dependencies in std case. We had to do this way because unfortunately there is no mechanism to enable a dependency if a feature is disabled. See further discussions about this. The big downside of std feature is although it is enabled by default, contracts and packages that do default-features = false for cosmwasm-std will also need to add std feature now.
• resolver = "2" is added to the root Cargo.toml. This solves a weird dependency error which breaks no_std builds. Unfortunately, Cargo unifies features of dev-dependencies and dependencies. This causes std feature to be enabled because of dev-dependencies and it breaks no_std builds. This resolver can be avoided if we were to use nightly for no_std builds in CI and use -Z avoid-dev-deps instead. What do you think?

[webmaster128]

Hey @webmaster128, I realized that splitting this will bring too many changes as well as some breaking ones. So it is best to stick with a single std imo.

This is in line with my thinking in #1484 (comment). Happy to continue like this.

• std feature is used instead of no_std to be able to enable optional dependencies in std case. We had to do this way because unfortunately there is no mechanism to enable a dependency if a feature is enabled. See further discussions about this. The big downside of std feature is although it is enabled by default, contracts and packages that do default-features = false for cosmwasm-std will also need to add std feature now.

Right, sure. Features are not for disabling something. We'll have to think about semver in this case but a source code breaking 2.0 is upcoming anyways.

• resolver = "2" is added to the root Cargo.toml.

The resolver is good. It's better to use v2 for CosmWasm things. We had many issues with v1 before. I just thought "2" is the default resolver in Rust edition2021 projects.

[aeryz]

The resolver is good. It's better to use v2 for CosmWasm things. We had many issues with v1 before. I just thought "2" is the default resolver in Rust edition2021 projects.

I also thought about that but it doesn't work without the resolver. I think this is the reason.

[hussein-aitlahcen]

Let's add a no_std check in the CI by using a target without std such as thumbv7em-none-eabi. This will avoid silently breaking it.

[webmaster128]

I also thought about that but it doesn't work without the resolver. I think this is the reason.

Thanks. Pulled out into #1496. When you rebase on main, you have it there.

[aeryz]

Let's add a no_std check in the CI by using a target without std such as thumbv7em-none-eabi. This will avoid silently breaking it.

Agreed, if you are not truly on a no_std target, it compiles even if your dependencies are not no_std. This was the main reason why we missed serde-json-wasm being std in the first place.

[aeryz]

@webmaster128 now that everything seems to be working fine, what do you think about semver? Should this be a part of 2.0?

[webmaster128]

Should this be a part of 2.0?

Yeah, let's add the std feature in 2.0. There will be a few more feature changes, so this is a good opportunity.

[ethanfrey]

Thank you for this. Just saw the PR. What is the status here?

I ask as there is another PR CosmWasm/cw-storage-plus#26 that would build on such.

[ethanfrey]

I see removing stuff from no_std build, but I think both serde-json-wasm is essential for it to work. Maybe a PR to make that no-std friendly (it was forked from serde-json-core which was no-std and we added stuff).

Otherwise, how would a contract actually parse data? How would cw-storage-plus work?

[ethanfrey]

thiserror is a bit sad to lose also, but I guess not absolutely needed here?
Not sure how StdError will interact with other types without it.

[ethanfrey]

In no-std, StdError: Error will not be implemented, right?

I think it would be good to make some alternative implementation for no-std, so we can at least have to_string() and treat it like an error.

[aeryz]

@ethanfrey @webmaster128 I don't work at composable anymore and don't have access to the fork. cc @dzmitry-lahoda for further discussions.

[dzmitry-lahoda]

I replacing this PR with new one.

[webmaster128]

I don't have a need for this but happy to include it in cosmwasm-std 2.0 (soonish). I'd like to reduce the negative impact of our regular non-no_std users. Adding a std feature as a breaking change for cosmwasm-std 2.0 is fine.

[dzmitry-lahoda]

@webmaster128 soonish is when?

[dzmitry-lahoda]

@webmaster128 what breaking change are you referring too?

[webmaster128]

@webmaster128 soonish is when?

This summer, June/July. Worst case August. The rest of 2.0 is tracked here and will be burned down after 1.3 is out of the door.

@webmaster128 what breaking change are you referring too?

Adding a std feature is breaking for every crate that uses cosmwasm-std without default features. That includes a bunch of libraries that use cosmwasm-std.

[dzmitry-lahoda]

@webmaster128 i am doing other way. only if feature no-std enabled things will break. but if people are doing --no-default-features --featrues=.... and do not add no-std features they are ok. so it will no break.

is that better? (if september would be target we need to think about other strategy to handle things).

[dzmitry-lahoda]

no-std hack not worked, also i have patched serde-json-wasm well, i cannot handle all other libs to many, seems cheaper be on forks.

# this does not work as cfg works only with targets, in theory can enumerate targets for allowance, but super hacky
[target.'cfg(not(no_std))'.dependencies]
forward_ref = "1"

so we will be on forks

[dzmitry-lahoda]

#1956

[webmaster128]

We are now working towards a split into cosmwasm-core (no_std compatible) and cosmwasm-std. CosmWasm 2.1 will come with a first but almost empty cosmwasm-core. See #2136 for how we plan address the centralization issue of StdError.

Thanks everyone for pushing this discussion. Closing here