Support no_std

[IcyDefiance]

This PR adds an "std" feature that is enabled by default, which allows users to disable the Error trait when needed, while keeping the Display and From traits.

This is useful for libraries that would like to support no_std while using thiserror to reduce boilerplate. For example: https://github.com/bytecodealliance/cranelift/issues/1261#issuecomment-589475011

[joshlf]

Thanks for doing this, @IcyDefiance ! This will unblock some work for us in Fuchsia.

[cuviper]

Note, this is technically a breaking change if anyone was already using thiserror with default-features = false, as they will now have reduced functionality.

I got burned by this when I added no_std to num crates -- rust-num/num#297. I've seen a lot of crates brush that off though, whether deliberate or not.

[Nemo157]

Would it be possible to introduce an alloc feature at the same time to avoid a second technically breaking change? Would there be enough functionality left without it active to make sense?

[tarcieri]

@Nemo157 an alloc feature would be nice if std::error::Error ever got moved to liballoc. Some discussion about that:

https://internals.rust-lang.org/t/can-we-move-std-error-to-core/11887/1

[IcyDefiance]

There was a PR to do that, but it was closed because it's incompatible with RFC 2504, which adds a backtrace thing. It's still possible that it'll be moved to alloc, but probably not anytime soon.

Aside from that, an alloc feature may have some use because it would still leave the From traits when it's disabled, but it would be even more complicated to support and avoid breaking in the future. I don't feel like I should make that decision, but I can implement it if dtolnay is okay with it.

I think I'll introduce no-std-compat tonight, though. I'll be able to eliminate the use of core that way, which will be a little easier to maintain.

[tarcieri]

@IcyDefiance if you're talking about this thread, the concern was what to do about backtrace in no_std environments, but... it seems like backtrace has no_std support?

rust-lang/rust#62502 (comment)

[shepmaster]

shepmaster/snafu#85 (comment)

At one point it “had” support but not really.

[shepmaster]

Consider using a shared alternate trait. See shepmaster/snafu#184

[Nemo157]

I wasn't even considering any eventual alloc::error::Error. I was just thinking about the fact that I have a no_std + optional-alloc + optional-std library so adding thiserror to reduce the error boilerplate would not be possible even after this PR; the alloc feature doesn't currently affect my errors at all, but the fact that thiserror links against alloc even with no-default-features makes it not fully no_std (so I would be satisfied if you could just remove the extern crate alloc, but I haven't spent the time to look through and see why it is there).

[Nemo157]

Re

an alloc feature [...] would be even more complicated to support and avoid breaking in the future

I haven't found that at all the case, you need to annotate some more things #[cfg(feature = "alloc")] but that's just more of the same as the step you take when introducing #[cfg(feature = "std")], there's nothing overly complicated about it. (And I personally find it much easier to just avoid anything like no_std_compat or as std hacks, just treat the standard library as a set of 3 crates and use appropriate paths for each item).

The biggest thing is to just ensure you have CI covering all three variations.

[dtolnay]

Thanks for the PR. I am concerned that this approach is brittle from a feature unification perspective. That is, if some no-std crate (particularly a library supporting std as well as no-std) has:

use thiserror::Error;

#[derive(Error, Debug)]
#[error("...")]
pub struct MyError;

impl core_error::Error for MyError {}

and anything else in the dependency graph enables thiserror/std and core-error/std then it causes breakage in the above correct code.

Same problem for:

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

Thoughts? Is there a different way to do no-std support in a way that doesn't cause breakage when only part of the dependency graph has no-std in mind?

[joshlf]

@dtolnay With respect to your first scenario, perhaps thiserror could derive core_error::Error when std is disabled so that the user would not need to write that impl manually?

With respect to your second scenario, I would think that it would be easier to have the hypothetical crate's std feature depend on thiserror/std instead of writing that code? We could presumably document that deriving Error AND having a manual impl of std::error::Error at the same time is unsupported?

[dtolnay]

Would it be workable for people if we emit an impl for "std::error::Error" unconditionally, and rely on downstream to have a "std" in scope that has whatever Error trait they want implemented?

// crate root
#![no_std]

mod std {
    pub mod error {
        pub use core_error::Error;

        // or, if you're not using sources and backtraces, maybe even:
        pub trait Error {}
    }
}


// module
use crate::std;
use thiserror::Error;

#[derive(Error, Debug)]
enum MyError {...}

I think this cleanly eliminates all bad interactions relating to feature unification.

[joshlf]

@dtolnay I agree that that would probably work, although I feel like it's pretty unidiomatic. So long as we're going to ask no_std users to do extra work, I feel like asking them to rely on thiserror/std if they provide a std feature themselves is more idiomatic. But I think your proposed solution would probably get the job done.

[tarcieri]

Personally I really dislike "fake std" approaches (e.g. use core as std) in truly (i.e. heapless) no_std environments.

For more featured environments, I'm a big fan of building out parts of std (and putting a mini/semi-std into the sysroot), but in truly heapless environments where developers really want to depend on libcore alone, I find approaches which pretend some minimal subset of std is available confusing and hard-to-debug (e.g. from a consumer-of-a-crate perspective, it calls into question whether std is actually needed or not)

[dtolnay]

@tarcieri that's a surprising distinction that I haven't heard before. I would be interested to dig into why it's okay for more featured environments to piece together a custom minimal std subset, but not okay in heapless environments.

Isn't using a derive(Error) inside a no-std crate precisely about "pretending some minimal subset of std is available"? It's possible this is arguing thiserror shouldn't support no-std in the first place.

[dtolnay]

I feel like asking them to rely on thiserror/std if they provide a std feature themselves is more idiomatic.

This only addresses the non-problematic direction, enabling thiserror/std if downstream/std is enabled. The problems come from inability to enable downstream/std if thiserror/std is enabled.

[tarcieri]

I would be interested to dig into why it's okay for more featured environments to piece together a custom minimal std subset, but not okay in heapless environments.

The distinction is more like as part of your project you intend to build out some meaningful subset of std functionality, versus other environments where literally everything the std facade provides beyond what's in libcore (or potentially liballoc too) is irrelevant to your use case.

std::error::Error is a notable oddity that IMO belongs in liballoc

[cuviper]

Would it be workable for people if we emit an impl for "std::error::Error" unconditionally, and rely on downstream to have a "std" in scope that has whatever Error trait they want implemented?

If it were just about the derived impl, I'd suggest having an explicitly separate derive that does everything but Error. However, you'll also have to reconsider thiserror::private::AsDynError -- did you already have something in mind for that in the downstream-"std" idea?

[tarcieri]

a bit off topic, but:

If you'd like a crate which provides a way to derive Display similar to thiserror which works on no_std, I'd recommend displaydoc:

https://github.com/yaahc/displaydoc

You'll still need to add something like:

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

...but otherwise it will still allow you to derive Display in a no_std-friendly way.

[shepmaster]

Another alternative crate that supports managing no_std compatible errors at this point in time is SNAFU