Skip to content
This repository was archived by the owner on Aug 16, 2021. It is now read-only.
This repository was archived by the owner on Aug 16, 2021. It is now read-only.

no_std support #138

@tarcieri

Description

@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.

Activity

Yamakaky

Yamakaky commented on Apr 3, 2017

@Yamakaky
Contributor

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

lucab

lucab commented on May 31, 2017

@lucab

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

tarcieri

tarcieri commented on Jun 2, 2017

@tarcieri
Author

I'm going to take a crack at this

tarcieri

tarcieri commented on Jun 2, 2017

@tarcieri
Author

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

tarcieri commented on Jun 3, 2017

@tarcieri
Author

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

tarcieri commented on Jun 8, 2017

@tarcieri
Author

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

tarcieri commented on Jun 8, 2017

@tarcieri
Author

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

brson commented on Jul 24, 2017

@brson
Contributor

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

Yamakaky

Yamakaky commented on Jul 24, 2017

@Yamakaky
Contributor

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

tarcieri

tarcieri commented on Jul 24, 2017

@tarcieri
Author

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.

added this to the 1.0 milestone on Jul 25, 2017
Yamakaky

Yamakaky commented on Jul 25, 2017

@Yamakaky
Contributor

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

tarcieri commented on Jul 25, 2017

@tarcieri
Author

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

Yamakaky commented on Jul 25, 2017

@Yamakaky
Contributor

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

tarcieri

tarcieri commented on Jul 25, 2017

@tarcieri
Author

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

Yamakaky commented on Jul 25, 2017

@Yamakaky
Contributor

OK then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @tarcieri@lucab@brson@Yamakaky

        Issue actions

          no_std support · Issue #138 · rust-lang-deprecated/error-chain