no_std support

[tarcieri]

It would be neat if this crate worked with #![no_std]. The main thing it's using seems to be Box, which could use collections in a no_std context.

If there's interest in gating the std stuff it uses on a cargo feature, I might be interested in submitting a PR.

[Yamakaky]

Yeah, sure! I guess it would mean disabling the error chain, and maybe the backtrace.

[lucab]

Bump of this. I'd like to see a backtrace-less no_std option too.

[tarcieri]

I'm going to take a crack at this

[tarcieri]

Okay, hit a snag: error-chain heavily depends on std::error, but it is not available in core.

Unless anyone knows of a resolution, this seems like a bit of a showstopper.

[tarcieri]

Went ahead and reopened this as on a second look I think it might be possible to gate std::error usages on a cargo feature. I'll further investigate

[tarcieri]

I attempted to vendor a minimalist version of the std::error::Error trait into error-chain itself for use in no_std contexts. That "worked" (although does not seem like a particularly good solution). Things still got rather tricky with the error chain macros (from error_chain.rs), as these are referred to using ::std. I tried to modify the macros to make them selectable (using e.g. a $core variable) but this got rather ugly.

I'm beginning to think this might be more trouble than it's worth.

[tarcieri]

Okay, so I managed to get error-chain to work with no_std, but it's not pretty:

#157

I'm not sure I'd actually want to use this unless I could get it upstream, and I think there's definitely a lot of cleanup that needs to happen first.

That said, the tests pass and cargo build --no-default-features succeeds.

[brson]

Current resolution is to push the Error trait further down into probably the alloc crate, which will make this easier.

[Yamakaky]

Hum, but if you user no_core, you don't have access to alloc, do you?

[tarcieri]

You can allocate from no_std, but you have to use #[feature(alloc)], which is ostensibly nightly-only as liballoc is not yet stable. My #157 PR is doing something similar except it's out-of-date at this point and using #[feature(collections)] instead.

I have been trying to figure out the least horrible way to do this over on the bytes crate. Here's an open PR which adds support for allocator-specific features for use with no_std:

https://github.com/carllerche/bytes/pull/153/files#r127882795

What I ended up settling on was having separate allocator, nightly, and std features, with allocator automatically included in either nightly or `std.

The nightly feature gates the use of #[feature(alloc)] and adds Box, String, and Vec to a custom crate prelude.

This approach makes the overall surface of the nightly feature very small. On the bytes crate it's approximately 10 lines, all contained within lib.rs.

[Yamakaky]

But then if you want core but not alloc, you can't use error_chain since it would require alloc even if it doesn't need it for allocating.

[tarcieri]

From a practical perspective yes. We can gate everything that needs an allocator on the allocator feature, but there wouldn't be a lot left with allocator disabled. While it'd compile, it wouldn't exactly be in a usable state.

[Yamakaky]

I'm thinking more about Error, which I don't really see why it will be in alloc...

[tarcieri]

From error.rs:

https://github.com/rust-lang/rust/blob/master/src/libstd/error.rs#L45

to create the blanket impls for Box required knowing that &str: !Error

Unfortunately Error is entangled with Box, which is allegedly why it can't be in libcore

[Yamakaky]

OK then