You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 16, 2021. It is now read-only.
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.
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:
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.
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.
Activity
Yamakaky commentedon Apr 3, 2017
Yeah, sure! I guess it would mean disabling the error chain, and maybe the backtrace.
lucab commentedon May 31, 2017
Bump of this. I'd like to see a backtrace-less
no_std
option too.tarcieri commentedon Jun 2, 2017
I'm going to take a crack at this
tarcieri commentedon Jun 2, 2017
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 commentedon Jun 3, 2017
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 investigaterust: Fix no_std support (removes error-chain)
tarcieri commentedon Jun 8, 2017
I attempted to vendor a minimalist version of the
std::error::Error
trait into error-chain itself for use inno_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 commentedon Jun 8, 2017
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 commentedon Jul 24, 2017
Current resolution is to push the Error trait further down into probably the alloc crate, which will make this easier.
Yamakaky commentedon Jul 24, 2017
Hum, but if you user no_core, you don't have access to alloc, do you?
tarcieri commentedon Jul 24, 2017
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 withno_std
:https://github.com/carllerche/bytes/pull/153/files#r127882795
What I ended up settling on was having separate
allocator
,nightly
, andstd
features, withallocator
automatically included in eithernightly
or `std.The
nightly
feature gates the use of#[feature(alloc)]
and addsBox
,String
, andVec
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 withinlib.rs
.Yamakaky commentedon Jul 25, 2017
But then if you want
core
but notalloc
, you can't useerror_chain
since it would requirealloc
even if it doesn't need it for allocating.tarcieri commentedon Jul 25, 2017
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 withallocator
disabled. While it'd compile, it wouldn't exactly be in a usable state.Yamakaky commentedon Jul 25, 2017
I'm thinking more about Error, which I don't really see why it will be in alloc...
tarcieri commentedon Jul 25, 2017
From error.rs:
https://github.com/rust-lang/rust/blob/master/src/libstd/error.rs#L45
Unfortunately
Error
is entangled withBox
, which is allegedly why it can't be in libcoreYamakaky commentedon Jul 25, 2017
OK then
rust: Fix no_std support (removes error-chain)