`extern crate alloc` pulled in without alloc feature
- Dominant language
- Rust
- Stars
- 4.1k
- Forks
- 339
- PR merge metrics
- No merged PRs in 30d
Description
The use of `extern crate alloc` is unconditional, which is odd given there is an alloc feature.
My expectation would be that
* everything that doesn't even depend on alloc is always built,
* what needs heap allocation is only built when `cfg(feature = "alloc")`,
* what has std dependencies is only built when `cfg(feature = "std")` (which entails alloc).
If that is the project's intention (and just not tested on a no-alloc system), there's a few changes I have up the pipeline but don't want to clean up to pull readiness until there is confirmation that this is how it's supposed to be:
* Guard `extern crate alloc` by the alloc feature; doing this shows there's also one or two other things that need guarding (the utils::Context trait)
* Split up the `unstable` feature into `unstable-core` and `unstable` (where the latter now depends on `unstable-core` for compatibility, and keeps pulling in `std`)
* Make building the prelude unconditional but only include what's active (currently, the prelude is only built for std -- but the prelude is the only place through which things like FutureExt are published)
* Remove from behind the cfg_alloc guard some (I won't even try to find all) things that don't really depend on alloc. The `race` function is what I'm actually doing this all for, as I don't want to implement it myself again. (Would be *way* less effort, now considering -- but doing it right may give me access to other useful traits on the long run).
* Replace `std` with `core` where needed for all of that.
* Figure out a way to do a meaningful test build that'd fail if anything tries to alloc. (Which is not all that simple because programs have a tendency to build even if their dependencies wouldn't as long as they don't use them).
Please let me know if the proposed is in line with the project's style, then I can hammer things out into a PR.
Contributor guide
Assessment
This issue has not been assessed yet.