-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge crate collections
into alloc
#42648
Conversation
r? @sfackler (rust_highfive has picked a reviewer for you, use r? to override) |
Looks great to me, thanks @murarth! Just to make sure it's written here, the rationale for this is:
|
Oh and let's just wait for a green travis build on this, then I'll r+ |
cc @rust-lang/libs |
☔ The latest upstream changes (presumably #42644) made this pull request unmergeable. Please resolve the merge conflicts. |
Looks like the linkchecker also turned up errors :( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Could update liballoc/lib.rs to mention that collections stuff is included in there as well.
Here's my late-night first-draft suggestion.
diff --git a/src/liballoc/lib.rs b/src/liballoc/lib.rs
index c70d823..d175fa4 100644
--- a/src/liballoc/lib.rs
+++ b/src/liballoc/lib.rs
@@ -10,17 +10,20 @@
//! # The Rust core allocation library
//!
-//! This is the lowest level library through which allocation in Rust can be
-//! performed.
+//! This is a low-level library which builds on libcore to add data structures
+//! which require dynamic memory allocation.
//!
//! This library, like libcore, is not intended for general usage, but rather as
//! a building block of other libraries. The types and interfaces in this
//! library are reexported through the [standard library](../std/index.html),
//! and should not be used through this library.
//!
-//! Currently, there are four major definitions in this library.
+//! The components of this library can be divided into two major groups: smart
+//! pointers, and collections (from the old libcollections).
//!
-//! ## Boxed values
+//! ## Smart Pointers and Memory Allocation
+//!
+//! ### Boxed values
//!
//! The [`Box`](boxed/index.html) type is a smart pointer type. There can
//! only be one owner of a `Box`, and the owner can decide to mutate the
@@ -30,7 +33,7 @@
//! is the same as that of a pointer. Tree-like data structures are often built
//! with boxes because each node often has only one owner, the parent.
//!
-//! ## Reference counted pointers
+//! ### Reference counted pointers
//!
//! The [`Rc`](rc/index.html) type is a non-threadsafe reference-counted pointer
//! type intended for sharing memory within a thread. An `Rc` pointer wraps a
@@ -40,7 +43,7 @@
//! constraining for an application, and is often paired with the `Cell` or
//! `RefCell` types in order to allow mutation.
//!
-//! ## Atomically reference counted pointers
+//! ### Atomically reference counted pointers
//!
//! The [`Arc`](arc/index.html) type is the threadsafe equivalent of the `Rc`
//! type. It provides all the same functionality of `Rc`, except it requires
@@ -51,10 +54,57 @@
//! paired with synchronization primitives such as mutexes to allow mutation of
//! shared resources.
//!
-//! ## Heap interfaces
+//! ### Heap interfaces
//!
//! The [`heap`](heap/index.html) module defines the low-level interface to the
//! default global allocator. It is not compatible with the libc allocator API.
+//!
+//! ## Collections
+//!
+//! ### Vectors
+//!
+//! The [`vec`](FIXME) module defines a "vector", a contiguous growable array
+//! type with heap-allocated contents.
+//!
+//! ### Deques
+//!
+//! The [`vec_deque`](FIXME) module defines a double-ended queue implemented
+//! with a growable ring buffer.
+//!
+//! ### Strings
+//!
+//! The [`string`](FIXME) module defines a growable, heap-allocated string
+//! with a known length. Rust strings are always encoded in valid UTF-8.
+//!
+//! The [`str`](FIXME) module defines operations on "string slices",
+//! borrowed references to UTF-8 string data.
+//!
+//! ### Linked Lists
+//!
+//! The [`linked_list`](FIXME) module defines a doubly-linked list, with
+//! constant-time inserts at both ends. In most cases, [`Vec`] or
+//! [`VecDeque`] offer better performance.
+//!
+//! ### Binary Heaps
+//!
+//! The [`binary_heap`](FIXME) module defines a A priority queue implemented
+//! with a binary heap.
+//!
+//! ### Ranges
+//!
+//! The [`range`](FIXME) module defines range types and traits. These are
+//! usually created with the `..` and `..=` operators.
+//!
+//! ### Slices
+//!
+//! The [`slice`](FIXME) module defines operations on "slices", borrowed
+//! views into contiguous sequences.
+//!
+//! ### B-Trees
+//!
+//! The [`btree`](FIXME) module defines various types implemented using
+//! binary trees. This module includes implementations of maps, sets, and
+//! search algorithms on B-Trees.
#![crate_name = "alloc"]
#![crate_type = "rlib"]
I think I've fixed the linkchecker issues now. It seems I can't test it locally without building all the way to stage2, so I hope this does it. @mattico: It could use a mention of collections types. I don't want to try to compete with the wonderful documentation in |
@bors: r+ |
📌 Commit eadda76 has been approved by |
Sorry to be a wet blanked - and maybe there's something I'm missing here - but wouldn't it be better if |
@joshlf perhaps one day, but the crates as-is today are nowhere near architected for that. These are all unstable, we can change them at any time. |
@alexcrichton Fair enough; as long as we leave open the possibility :) |
@mattico Yep, I've been making plenty of noise over there too :) |
Merge crate `collections` into `alloc` This is a necessary step in order to merge #42565
Woah. Really scared about the end of fine-grain crates behind the facade. |
One thing I talked about in the local Allocator RFC is using an empty associated error type for infallibile allocation, and then immediately and easily using that for converting collections. |
For the stated problem, I think it makes more sense to simply move Vec to alloc. It is argubaly the most more fundamental data structure, and I'll guess we could get rid of this RawVec too. |
☀️ Test successful - status-appveyor, status-travis |
I'm somewhat overloaded right now, so that will have to be someone else... |
I wouldn't mind handling that. ~~~Should be a simple copy/paste of the re-exports in @alexcrichton: One question, though: Should the re-exports of the new |
We can't handle the reexports themselves being deprecated, but I think it's fine to deprecate the |
The `collections` crate was merged with `alloc` in rust-lang/rust#42648, which necessitated a change in how we depend on the std library collections in the kernel. This PR also renames the `alloc` crate to `sos_alloc`, to avoid the namespace clash with the std library's `alloc` crate on which we now depend.
Convert `Into<Box<[T]>> for Vec<T>` into `From<Vec<T>> for Box<[T]>` As the `collections` crate has been merged into `alloc` in rust-lang#42648 this impl is now possible. This is the final part of rust-lang#42129 missing from rust-lang#42227.
libcollections was deprecated in rust-lang/rust#42648 and its contents were moved to liballoc.
libcollections was deprecated in rust-lang/rust#42648 and its contents were moved to liballoc.
libcollections was deprecated in rust-lang/rust#42648 and its contents were moved to liballoc.
libcollections was deprecated in rust-lang/rust#42648 and its contents were moved to liballoc.
Merge the std_unicode crate into the core crate [The standard library facade](#27783) has historically contained a number of crates with different roles, but that number has decreased over time. `rand` and `libc` have moved to crates.io, and [`collections` was merged into `alloc`](#42648). Today we have `core` that applies everywhere, `std` that expects a full operating system, and `alloc` in-between that only requires a memory allocator (which can be provided by users)… and `std_unicode`, which doesn’t really have a reason to be separate anymore. It contains functionality based on Unicode data tables that can be large, but as long as relevant functions are not called the tables should be removed from binaries by linkers. This deprecates the unstable `std_unicode` crate and moves all of its contents into `core`, replacing them with `pub use` reexports. The crate can be removed later. This also removes the `CharExt` trait (replaced with inherent methods in libcore) and `UnicodeStr` trait (merged into `StrExt`). There traits were both unstable and not intended to be used or named directly. A number of new items are newly-available in libcore and instantly stable there, but only if they were already stable in libstd. Fixes #49319.
Merge the std_unicode crate into the core crate [The standard library facade](#27783) has historically contained a number of crates with different roles, but that number has decreased over time. `rand` and `libc` have moved to crates.io, and [`collections` was merged into `alloc`](#42648). Today we have `core` that applies everywhere, `std` that expects a full operating system, and `alloc` in-between that only requires a memory allocator (which can be provided by users)… and `std_unicode`, which doesn’t really have a reason to be separate anymore. It contains functionality based on Unicode data tables that can be large, but as long as relevant functions are not called the tables should be removed from binaries by linkers. This deprecates the unstable `std_unicode` crate and moves all of its contents into `core`, replacing them with `pub use` reexports. The crate can be removed later. This also removes the `CharExt` trait (replaced with inherent methods in libcore) and `UnicodeStr` trait (merged into `StrExt`). There traits were both unstable and not intended to be used or named directly. A number of new items are newly-available in libcore and instantly stable there, but only if they were already stable in libstd. Fixes #49319.
…ts, r=cuviper Rename `{collections=>alloc}{tests,benches}` The crate is named `alloc` so this makes more sense. Ig this is fallout from rust-lang#42648?
Rollup merge of rust-lang#118314 - WaffleLapkin:rename_collectionstests, r=cuviper Rename `{collections=>alloc}{tests,benches}` The crate is named `alloc` so this makes more sense. Ig this is fallout from rust-lang#42648?
libcollections was recently merged into liballoc: rust-lang/rust#42648 I went ahead and also added an "alloc" feature which no_std users can use to opt into liballoc features (i.e. any code using Vec). This should have no effect on anything but no_std usage. It does make it possible for people without allocators to use curve25519-dalek if they want though. Might be nice for "bare metal" development. All that said, from what I can gather liballoc, while not "stable", should likely stick around for the forseeable future. Some backstory on the liballoc/libcollections merge here: rust-lang/rust#42565
This is a necessary step in order to merge #42565