Errors when using ethereum-types in no_std context

[moriaab]

When trying to use ethereum-types in no_std context:
ethereum-types = { version = "0.3", default-features = false }
get the following errors:

error: cannot find macro `format!` in this scope
  --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/ethereum-types-0.3.2/src/hash.rs:72:1
   |
72 | construct_hash!(H32, 4);
   | ^^^^^^^^^^^^^^^^^^^^^^^^
   |
   
error[E0412]: cannot find type `String` in this scope
  --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/ethereum-types-0.3.2/src/hash.rs:73:1
   |
73 | construct_hash!(H64, 8);
   | ^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope

[niklasad1]

Ok, I haven't tested but I think we need to explictly use alloc crate to use heap allocated things such as String

I guess we need something like

#[cfg(not(feature = "std"))] {
mod no_std {
  extern crate alloc;
  pub use alloc::string::{String, ToString};
  pub use alloc::vec::Vec;
}

[moriaab]

Thank you, but can you please give me an example how should I use this?

[tomusdrw]

@niklasad1 Do we actually need the function causing issues in no_std? Maybe let's just remove it in that context.

[niklasad1]

@tomusdrw Good question, I will check it out!

But it compiles using alloc and exporting String and ToOwned but I was unlucky before missed to disable the default-features so I accidental compiled both std and no_std for ethereum_types lol!

[niklasad1]

@tomusdrw

So I have looked a bit at this and the problem is that ethbloom requires std via its features and compiles fixed_hash as std and that cases all these errors.

So, the easiest way to fix this would be

[target.'cfg(not(feature = "std"))'.dependencies]
ethbloom = { path = "../ethbloom", version = "0.5.0", default-features = false }

[target.'cfg(feature = "std")'.dependencies]
ethbloom = { path = "../ethbloom", version = "0.5.0"}

But, ofcourse this doesn't work yet /cc rust-lang/cargo#2524

So, we need to refactor the features in ethbloom to solve this otherwise we will end up with both std and no-std!

[tomusdrw]

why not include ethbloom without default features always? and then relay the same features on ethereum-types (which is already done anyway I believe; so ethereum-types/std implies ethbloom/std)

[niklasad1]

Yeah, you are right that's clever submitting PR soon!

[niklasad1]

ethereum-types 0.4 is now released which solved this issue!