"allocator" and "nightly" features (for no_std environments) #153
Conversation
|
Note this PR includes a commit from the |
| @@ -70,8 +70,16 @@ | |||
|
|
|||
| #![deny(warnings, missing_docs, missing_debug_implementations)] | |||
| #![doc(html_root_url = "https://docs.rs/bytes/0.4")] | |||
| #![cfg_attr(not(feature = "std"), no_std)] | |||
| #![cfg_attr(feature = "nightly", feature(alloc))] | |||
There was a problem hiding this comment.
@alexcrichton so really this is the part that requires nightly, and that's because even if I have an #[allocator] defined Box, Vec, and String do not get added to the prelude.
If they did, then we could simply have an enabled-by-default, non-nightly-dependent alloc cargo feature for gating features that depend on Box, Vec, and String.
I'm not sure how hard that would be, but I imagine it would be immensely useful for no_std users who have a heap available.
tonychain
force-pushed
the
alloc
branch
2 times, most recently
from
d0a74b1
to
a57e18b
Compare
tonychain
changed the title
| @@ -98,3 +110,15 @@ pub use byteorder::{ByteOrder, BigEndian, LittleEndian}; | |||
| #[cfg(feature = "serde")] | |||
| #[doc(hidden)] | |||
| pub mod serde; | |||
|
|
|||
| /// Custom (internal-only) prelude for this module | |||
There was a problem hiding this comment.
I made this to avoid having to individually import each of these types everywhere they're used.
Seems like a bit of a hack, but dramatically reduces the scope of what the nightly feature does which I think is nice.
It also makes this easy to change in the event the liballoc/libcollections merge is reverted
- Changes all references to libcore features from ::std to ::core - Feature gates anything dependent on std on the "std" feature
This commit gates all allocator-dependent features on an "allocator" feature. It also adds a "nightly" feature which enables using the "allocator" feature in no_std environments. This requires using #[feature(alloc)] which requires nightly. The "allocator" feature is automatically enabled when either the "std" or "nightly" features are enabled. Travis CI is configured to check that builds succeed with both the "nightly" feature along with "std" and "nightly" in combination. To avoid the problem of nightly changes breaking the build, these combinations are specifically flagged as allowed failures in the Travis CI configuration.
|
Hey @carllerche. I'd love to see |
|
Sorry to have left this without a response. I don't think we want to add a dependency (even hidden behind a feature flag) on the allocator crate as it is highly unstable. #135 is fine as an approach to support I'm going to close this for now as #135 is the preferred path forward. |
|
So the argument behind rust-lang/rfcs#2480 is that while |
|
If rust-lang/rfcs#2480 lands, this will all work on stable. At that time I will happily revive this PR. |
|
@tarcieri I am commenting here and there because I both want this PR and ones like it really badly and don't want to stabilize |
|
I have seen the stable build break due to adding nightly only features guarded with a feature flag. |
This gates all allocator-dependent features on an "allocator" feature.
It also adds a "nightly" feature which enables using the "allocator" feature in no_std environments. This requires using
#[feature(alloc)]which requires nightly.The "allocator" feature is automatically enabled when either the "std" or "nightly" features are enabled.
Travis CI is configured to check that builds succeed with both the "nightly" feature along with "std" and "nightly" in combination. To avoid the problem of nightly changes breaking the build, these combinations are specifically flagged as allowed failures in the Travis CI configuration.