`no_std` compatibility: handling the 4 incompatible crates

[livelybug]

@romac In ibc-rs module and dependencies.tendermint module, there are 4 crates that's incompatible with no-std, as below:

• anomaly: to be removed? Use flex-error to define errors #988
• thiserror Use flex-error to define errors #988
• serde-repr: replace with alternative? no longer relevant
• toml

If you have any progress of processing the crates above for no-std please update here, thank you.

[romac]

anomaly

Yes, we need to remove it.

thiserror

Replace with displaydoc and a conditional std::error:Error instance.
See dtolnay/thiserror#64 (comment)

serde-repr

It looks like this crate is not used at all in tendermint, and we can thus just remove it from the dependencies.

toml

This crate is only used to parse a Tendermint configuration file. I would suggest only defining this function when no_std is not set, and thus only enable the toml dependency when the std feature is enabled.

@livelybug Does this make sense to you?

[romac]

Note that we often use the .context method of anomaly to provide more context when throwing an error. Each use of .context should therefore be replace with a specific error variant:

Before:

use thiserror::Error;

type Error = anomaly::Error<Kind>;

#[derive(Clone, Debug, Error, PartialEq, Eq)]
enum Kind {
   #[error("foo error")]
    Foo,
}

fn some_func() -> Result<(), Error> {
  if true {
    Err(Kind::Foo.context(format!("bar: {}", n)).into())
  } else {
    Err(Kind::Foo.context("baz").into())
  }
}

After

use displaydoc::Display;

#[derive(Clone, Debug, Display, ...)]
enum Foo {
  /// bar: {0}
  Baz(i32),
  /// baz
  Baz
}

#[cfg(feature = "std")]
impl std::error::Error for Foo {}

#[derive(Clone, Debug, Display, ...)]
enum Error {
   /// Foo error: {0}
    Foo(Foo),
}

#[cfg(feature = "std")]
impl std::error::Error for Error {}

fn some_func(n: i32) -> Result<(), Error> {
  if true {
    Err(Kind::Foo(Foo::Bar(n)))
  } else {
    Err(Kind::Foo(Foo::Baz))
  }
}

[soareschen]

I'm not sure if the proposed composition of Foo and Bar errors handle the stack traces well? Actually, with this the backtrace is not captured at all. Or perhaps backtraces are not that useful in practice? (I don't really need it personally, just thought some developers may find the backtraces useful)

[romac]

That's a good point, thanks! I will investigate to see if we can somehow retain backtraces when std is enabled. Backtraces are indeed useful imho but if we retain them at the relayer and relayer-cli it might be enough for our needs, cf. informalsystems/ibc-rs#950 (comment).

[DaviRain-Su]

anomaly

Yes, we need to remove it.

thiserror

Replace with displaydoc and a conditional std::error:Error instance.
See dtolnay/thiserror#64 (comment)

serde-repr

It looks like this crate is not used at all in tendermint, and we can thus just remove it from the dependencies.

toml

This crate is only used to parse a Tendermint configuration file. I would suggest only defining this function when no_std is not set, and thus only enable the toml dependency when the std feature is enabled.

@livelybug Does this make sense to you?

hi, For anomaly crate, have you some advise? I am try to use anyhow to re-code.

[DaviRain-Su]

anomaly

Yes, we need to remove it.

thiserror

Replace with displaydoc and a conditional std::error:Error instance.
See dtolnay/thiserror#64 (comment)

serde-repr

It looks like this crate is not used at all in tendermint, and we can thus just remove it from the dependencies.

toml

This crate is only used to parse a Tendermint configuration file. I would suggest only defining this function when no_std is not set, and thus only enable the toml dependency when the std feature is enabled.

@livelybug Does this make sense to you?

I have re-code, and meet some error, for anomaly. I see your use eyre move to anomaly, I have been do this. But, in no_std env, eyre and displaydoc (support no_std thiserror replace displaydoc). Have been some error. So I use anyhow and displaydoc to do this, But I have other error. cometbft/tendermint-rs#884

[romac]

For anomaly crate, have you some advise? I am try to use anyhow to re-code.

I was thinking we would not use any error handling library at all, just displaydoc as mentioned above.

@soareschen What do you think we should do there? Do you see any value on using anyhow in the ibc crate?

[DaviRain-Su]

I am re-code by anomaly move to eyre and pare with displaydoc to handle with this, I meet some error, then, use anyhow and display have no some problem, but meet time mod have some error in no_std env.