Make CosmWasm std package no_std capable
#1484
Comments
|
Picking up yesterday's thoughts on extracting a minimal interface package shared between cosmwasm-std and cosmwasm-vm (#1483): Creating yet another package comes with significant drawbacks wrt. documentation. A contract developer only should bother about cosmwasm-std. All relevant symbols and their documentation should be in https://docs.rs/cosmwasm-std/latest/cosmwasm_std/. If we extract some parts, it adds more indirection and the contract developer suddenly has to worry about the difference between the packages even if they are exported through cosmwasm_std. I think we should focus on dev UX and rather spend 10 days maintaining the codebase if it save the contract dev 10 minutes navigating. cosmwasm-std is maintained by a handfull of highly skilled devs very familiar with the codebase and committed to it for months. But it is used by hundreds of devs in various levels from absolute beginner/Rust newbie to advanced blockchain dev. So optimizing for cosmwasm-std maintenance convenience feels wrong. Looking at #1483 the diff is not all that scary to me. cosmwasm-std has few dependencies and I think it's worth evaluating their no_std compatibility.
|
std::error::Error doesn’t currently have a stable no_std equivalence. core::error::Error is a thing but it’s unstable and thus requires nightly compiler. There’s one hack we can use. serde has no_std support and exports std::error::Error as serde::de::StdErr. This way we hide the need for nightly compiler to serde. The two alternatives are: - require nightly compiler or - don’t implement std::error::Error in no_std builds. Issue: CosmWasm#1484
std::error::Error doesn’t currently have a stable no_std equivalence. core::error::Error is a thing but it’s unstable and thus requires nightly compiler. There’s one hack we can use. serde has no_std support and exports std::error::Error as serde::de::StdErr. This way we hide the need for nightly compiler to serde. The two alternatives are: - require nightly compiler or - don’t implement std::error::Error in no_std builds. Issue: CosmWasm#1484
Eliminate all uses of std crate from non-test code. For the most part
it is a matter of using core or alloc namespaces instead.
The only exception is std::error::Error trait. However, it is
re-exported by serde as serde::{de,ser}::StdError so implement that
instead.
Tests use HashMap which requires std crate. Since test code doesn’t
matter for no_std support, enable std crate when building tests.
no_std support was tested by building for thumbv6m-none-eabi target.
Issue: CosmWasm/cosmwasm#1484
Issue: CosmWasm#40
Even though the crate doesn’t use std crate, because it doesn’t
declare `#![no_std]` it cannot be compiled in no_std environments:
error[E0463]: can't find crate for `std`
= note: the `thumbv6m-none-eabi` target may not support the standard library
= note: `std` is required by `forward_ref` because it does not declare `#![no_std]`
Adding the annotation makes it possible to use the crate on no_std
targets.
Issue: CosmWasm/cosmwasm#1484
Remove all references to std from the library and introduce std and
unstable features which enable corresponding serde features.
In default build, std is enabled and nothing changes. However, if std
is disabled, the library becomes no_std. Downside of lack of std is
that Error enum no longer implements std::error;:Error. To remedy that,
unstable feature uses core::error::Error but requires a nightly compiler.
For the most part, this commit is mostly just replacing references to
std crate with core and alloc crates. On exception is std::error::Error
which is replaced by serde’s StdError such that Error enums implement
whatever trait serde uses. With std or unstable feature enabled it’s
just an alias to {std,core}::error::Error.
Issue: CosmWasm/cosmwasm#1484
Issue: CosmWasm#40
I have a PR for it. The crate pretty much is no_std except that it lacks the necessary annotation. However, the PR is sitting in limbo so I dunno if the project isn’t abandoned.
schemars is only used for generating the schema as far as I understand and as such it isn’t cross-compiled to no_std targets. Changing
Both have no_std support. serde-json-wasm in the newly released 1.0 version. In both cases no_std support requires nightly compiler (this is due to core::error::Error).
May I suggest a bold option: stop supporting I’ve sent a PR adding no_std support however dtolnay rejected it on the grounds that it requires nightly compiler. There is thiserror-core fork which does support no_std so that’s also an option. I’ll try to push some preparation PRs to thiserror to make it so that the fork will have smaller diff to upstream. |
|
#1971 will create an For now a build without Thanks everyone |
Remove all references to std from the library and introduce std and
unstable features which enable corresponding serde features.
In default build, std is enabled and nothing changes. However, if std
is disabled, the library becomes no_std. Downside of lack of std is
that Error enum no longer implements std::error;:Error. To remedy that,
unstable feature uses core::error::Error but requires a nightly compiler.
For the most part, this commit is mostly just replacing references to
std crate with core and alloc crates. On exception is std::error::Error
which is replaced by serde’s StdError such that Error enums implement
whatever trait serde uses. With std or unstable feature enabled it’s
just an alias to {std,core}::error::Error.
Issue: CosmWasm/cosmwasm#1484
Issue: #40
Hey, making the CosmWasm std package
no_stdcapable would allow third parties to use it in more constrained environments. At Composable we run a CosmWasm VM under a Substrate pallet (equivalent of Cosmos module) and this require the dependencies to beno_std(targeting wasm32).When prototyping the VM, we initially copied parts of the std (as we are only interested in the types for the VM) and we now think that it is the good moment to deprecate this forked std in favor of the official one.
Consequently, having the PR #1483 merged would drastically improve the interface of the alternative VM and also allow us to maintain it by following the CosmWasm upgrades.
The text was updated successfully, but these errors were encountered: