Tracking issue for location of facade crates

We probably don't want to indefinitely have a large number of facade crates which are all unstable, so we should eventually stabilize these crates, fold them back into the standard library, or find a good middle ground in which they can all reside.

The current set of crates considered under this issue are:

rustc_unicode
libc
collections
alloc
rand

Update 2018-04-05:

libc and rand have moved to crates.io
collections was merged into alloc
rustc_unicode was renamed to std_unicode and later merged into core

This leaves only the alloc crate still unstable, which with the stable core and std crates (plus arguably proc_macro) form the standard library.

Update 2018-06-19:

RFC 2480 proposes stabilizing the alloc crate, which would close this issue.

It has been noted that the separation between alloc and collections is seemingly arbitrary. However with a robust allocator API, it could be possible to specify collections without any allocator. So e.g. no_std users could provide their own allocator and still use Vec.

Basically I don't think these should be stabilized at all in anything approaching the short term pending the ultimate allocator designs.

Found this through alloc documents.

Is there any news about this issue?
btw, I just want a RawVec for custom data-structures.

RawVec would be great. Any way to allocate memory other than Vec::with_capacity + mem::forget would be nice.

@chao787 that's the alloc crate.

I've found this issue through compiler error message:

error: use of unstable library feature 'alloc_system': this library is unlikely to be stabilized in its current form or name (see issue #27783)

I'm just trying to opt out of jemalloc and get Rust to compile my binary with system default malloc implementation. Is there a way to do it that would not involve unstable language features, like a compiler switch to get jemalloc out of my binaries and off my lawn?

Rationale: jemalloc has abysmal fork performance (80x slowdown) on default kernel configuration of recent Ubuntu. See issue #36705 for more info.

Opting out of jemalloc is also important for fuzzing, e.g. with afl-fuzz; even on jemalloc-friendly configurations using default malloc gets you 20% more fork performance which is significant for fuzzing workloads, and lets you substitute abusive memory allocators at runtime that catch more errors than default allocator or jemalloc but don't incur the performance penalty of DUMA or AddressSanitizer. See AFL's libdislocator as an example.

@Shnatsel

@Shnatsel yeah I'd love to explore the possibilities of stabilizing the "please give me the system allocator" intent. Right now it's unfortunately not possible to do that in stable Rust.

The tracking issue for global allocators in general is #27389, but it may be worth spawning off a separate thread of discussion for just declaring the intent to use the system allocator.

FWIW I'm not in favor of merging the facade crates. Having std be decomposed into reusable components should be useful for those targeting more exotic systems, particularly if I complete my further ambitions to extract all system-specific components of std into their own crates. Ultimately people should be able to create custom stds for whatever weird systems they want be reusing our small self-contained building blocks.

Decomposed stdlib would be really useful for asm.js target that I will need in the near future and really want to use Rust for.

@brson

@brson As a person targeting a mildly exotic system, I agree. For example, I would expect that a significant proportion of bare-metal use cases (like mine) would want alloc and collections but nothing beyond.

The current set of crates considered under this issue are:

rustc_unicode

libc

collections

alloc

rand

I surveyed what’s tracked by this issue when writing #39954. Unless I missed something:

libc and rand are now available on crates.io.
All functionality in collections is re-exported as stable in std, is deprecated, or has a more specific tracking issue.
Some non-deprecated functionality in std_unicode (formerly rustc_unicode) and alloc is re-exported as stable in std.
Functionality not available on stable Rust is:
- alloc::heap
  - When a type T can be written such as mem::align_of::<T>() is the desired alignment, Vec + mem::forget can be used to re-implement allocate, deallocate, and reallocate.
  - As far as I know, no such work-around is possible for reallocate_inplace or usable_size.
  - EMPTY is “known” to be 1 as *mut (), but keeping a separate definition and assuming it keeps matching alloc’s seems fragile
- alloc::oom
- alloc::raw_vec
- std_unicode::derived_property
- std_unicode::property
- ~~std_unicode::str::is_utf16~~ Remove std_unicode::str::is_utf16 #40190
- ~~std_unicode::str::utf8_char_width~~ Reduce std_unicode’s public API #40189
- std_unicode::str::Utf16Encoder
Additional functionality not available on stable Rust with #![no_std]:
- alloc::arc
- alloc::boxed
- alloc::rc
- collections
- std_unicode::char
- std_unicode::str::UnicodeStr

Some environments might require #![no_std] because they lack threads for example, but still have a memory allocator available.

My subjective opinions:

derived_property, property, utf8_char_width, and raw_vec are public in order to be used in other crates. Arguably they’re not something we ever want to stabilize.
Utf16Encoder is almost in this category, but it is usefully more general than the stable str::encode_utf16 method since it works on arbitrary char iterators rather than just &str.
is_utf16 has never been used in the compiler or standard library since 47e7a05 added it in 2012 “for OS API interop”. It can be replaced with a one-liner: std::char::decode_utf16(s).all(|r| r.is_ok()). I propose removing it: Remove std_unicode::str::is_utf16 #40190

Looking at Utf16Encoder again, it’s based on char::encode_utf16 and so fairly easy to reproduce outside of std, so never mind. (Mostly, it’s only verbose because defining an iterator is verbose.)

I think this leaves two items in need of attention:

Stabilize raw memory allocation (alloc::heap, maybe also alloc::oom).
Figure out how to provide non-core functionality to #![no_std] crates.

I vaguely recall GC-related concerns about the former, but I think those would also apply to the Vec + mem::forget trick that is used on stable today. There’s even a crate for it: https://crates.io/crates/memalloc

Stabilize raw memory allocation

This is #27700, not sure how I missed that.

RFC 2480 proposes stabilizing the alloc crate, which would close this issue.

PR Make the public API of the alloc crate a subset of std #51569: Make the public API of the alloc crate a subset of std
PR Move OOM handling to liballoc and remove the oom lang item #51607: Move OOM handling to liballoc and remove the oom lang item
PR Update the error message for a missing global allocator #51639: Update the error message for a missing global allocator

There is something questionable with using alloc in a no_std context currently: you automatically get a global allocator without adding a #[global_allocator], and that allocator is jemalloc. I would have expected something similar to panic: a compiler error about the missing panic_implementation (which currently still talks about the lang item, but you get the point).

@glandium

@glandium #36963 should make this disappear, and it only happens for executables. A staticlib for example does get an error message: #51639, since the "default lib allocator" is not jemalloc and is defined in std.

But yeah it’s a good question whether we should change this in the meantime. Maybe it’s not much of a problem in practice?

Auto merge of #51569 - SimonSapin:liballoc, r=sfackler

How about adding getrandom to the OP list? (maybe instead of rand?) Introduction of a simple (overwritable) function for pulling entropy from system randomness source was previously briefly discussed here. See rust-random/getrandom for the current prototype.

RFC 2480 to stabilize the alloc crate was accepted. PR #59675 does so, and closes this issue since alloc was the last crate tracked here. (Others have been stabilized already, moved to crates.io, or merged into other crates.)

Stabilize the `alloc` crate.

Rollup merge of rust-lang#59675 - SimonSapin:stable-alloc, r=alexcric…

Navigation Menu

Repository navigation

Tracking issue for location of facade crates #27783

24 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for location of facade crates #27783

Description

Activity

Gankra commented on Aug 13, 2015

zitsen commented on Dec 16, 2015

SimonSapin commented on Dec 16, 2015

steveklabnik commented on Jan 5, 2016

Shnatsel commented on Oct 4, 2016

alexcrichton commented on Oct 4, 2016

brson commented on Oct 4, 2016

Shnatsel commented on Oct 4, 2016

whitequark commented on Oct 16, 2016

SimonSapin commented on Mar 1, 2017

SimonSapin commented on Mar 3, 2017

SimonSapin commented on Mar 29, 2017

24 remaining items

SimonSapin commented on Jun 19, 2018

glandium commented on Jun 20, 2018

SimonSapin commented on Jun 20, 2018

newpavlov commented on Feb 18, 2019

SimonSapin commented on Apr 3, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions