Non-Standardized Supporting

[AurevoirXavier]

I revamp my old implementation #211.

• All JSON tests were ignored under no-std.
• Reader/Tokenizer/serde/serde_jsonshould be enabled by --features full-serde.
  • I'm not sure if I should disable Writer in no-std, because I found it was used in signature.
• Error::FromUtf8Error removed, cause can't find any usage of it.
• All HashMap change to BTreeMap for no-std. !!BREAKING change!!

@sorpaas

[sorpaas]

I'd appreciate if you can add CI build run for no_std as well!

[vkgnosis]

Could you explain a bit on the motivation for no std support? What part of the crate is still useful without std? Why does HashMap have to change to BTreeMap?

[AurevoirXavier]

Could you explain a bit on the motivation for no std support? What part of the crate is still useful without std? Why does HashMap have to change to BTreeMap?

1. I found many people use this in substrate runtime, so do I. Some of them used it in EVM. And my team used it for the ethereum cross-chain bridge.
2. Reader/Tokenizer/serde/serde_json not available in no-std.
3. There is no HashMap under alloc. And we use BTreeMap to replace in general.

[AurevoirXavier]

I'd appreciate if you can add CI build run for no_std as well!

Okay.

Interesting, why the CI failed?

cargo test --no-default-features passed locally.

[sorpaas]

Please remove check and test command in CI, and add build.

[AurevoirXavier]

Please remove check and test command in CI, and add build.

Please review.

[sorpaas]

CI is failing!

[AurevoirXavier]

CI is failing!

I see. cargo-hack is pretty strict.

[sorpaas]

This is just wrong. By default std should be enabled.

[AurevoirXavier]

This is just wrong. By default std should be enabled.

But the full-serde contains std. Should I explicitly write it here again?

[AurevoirXavier]

Okay. I found a corner case. You're right.

[AurevoirXavier]

Sorry about ^^^

The full-serde is enabled by default. So std is always enabled by defualt.