add #![no_std] support

[tsatke]

I know of #64.

However, I saw an unstable feature in nightly, error_in_core, which adds core::error::Error. Maybe this is an additional incentive, to think about no_std support again.

[adsnaider]

Just pitching in, I believe rust-lang/project-error-handling#3 is the Rust issue in question that adds the Error trait to core.

[FlorianUekermann]

I need no_std support pretty badly, so I had a look at it and encountered no issues using error_in_core: FlorianUekermann@369f452

There isn't much more to it than replacing std:: with core:: in a couple of places and adding an std feature, which is active by default. Even this little addition to the __private module can be removed once error_in_core is stable:

#[doc(hidden)]
pub mod __private {
    #[cfg(not(feature = "std"))]
    pub use core::error;
    #[cfg(feature = "std")]
    pub use std::error;

Of course this only works on nightly for now,.

@dtolnay : Are you open to a PR?

[tsatke]

@FlorianUekermann if you have one, I would just send it. If @dtolnay is against the PR, I'd be happy to maintain a fork with no_std support.

[FlorianUekermann]

@tsatke

@FlorianUekermann if you have one, I would just send it. If @dtolnay is against the PR, I'd be happy to maintain a fork with no_std support.

I published the changes in the PR as thiserror-core for now, because I needed something on crates.io asap. Maybe you'll find that useful until something similar is merged.

[jsdw]

Would it be possible to simply remove the impl Error for Foo {} codegen when some "std" flag is disabled until it becomes possible to support Error in no_std properly? This way, we'd still get the nice Display/From impls that thiserror provides, as well as be able to use thiserror in crates that support no_std as well as std envs (fully benefitting in std envs and still partially benefitting in no_std ones).

As it stands, I've had to remove thiserror entirely from a few crates now as I've added optional no_std support to them and just implement Display/From manually on the errors and manually conditionally implement Error, which is a bit sucky.

[dtolnay]

I am not interested in no-std support until after Error in core is stable. I'll go ahead and close this issue and would ask for a new issue to be opened then.

[jsdw]

That's fair, and thank you for the excellent library!

I ended up using derive_more's From + Display impl and a manual impl Error behind an std feature flag, which worked for my use cases at least and saved most of the manual work :)

[parasyte]

You can use #[cfg_attr] if you just want to conditionally enable the Error derive when building with std library support.

#![cfg_attr(not(feature = "std"), no_std)]

#[derive(Debug)]
#[cfg_attr(feature = "std", derive(thiserror::Error))]
#[cfg_attr(feature = "std", error("Hello, world!"))]
pub struct Error();

I have also published an alternative derive crate that works with core::error if you need it today: https://docs.rs/onlyerror

[jordens]

For those that want to play with thiserror on no_std, there are now #211/#196 (comment) and master...quartiq:thiserror:no-std available, both minimally invasive using error_in_core on nightly with tests passing. Both address the issues raised in #64 AFAICS.

[AurevoirXavier]

It might be the time to reopen this, rust-lang/rust#103765.