Skip to content
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

Merged
merged 1 commit into from
Jun 15, 2017
Merged

Merge crate collections into alloc #42648

merged 1 commit into from
Jun 15, 2017

Conversation

murarth
Copy link
Contributor

@murarth murarth commented Jun 13, 2017

This is a necessary step in order to merge #42565

@rust-highfive
Copy link
Collaborator

r? @sfackler

(rust_highfive has picked a reviewer for you, use r? to override)

@murarth
Copy link
Contributor Author

murarth commented Jun 13, 2017

r? @alexcrichton

@alexcrichton
Copy link
Member

Looks great to me, thanks @murarth!

Just to make sure it's written here, the rationale for this is:

  • In Implement From<&[T]> and others for Arc/Rc (RFC 1845) #42565 the Rc and Vec types need to know about each other, specifically we want to write down From<Vec<T>> for Rc<T>
  • Historically there were plans to keep collections separate from alloc, but that never panned out.
  • Nowadays both alloc and collections add one additional assumption over libcore, dynamic memory allocation. There's not much reason any more to keep them separate as given one you can always have all of the other.

@alexcrichton
Copy link
Member

Oh and let's just wait for a green travis build on this, then I'll r+

@alexcrichton
Copy link
Member

cc @rust-lang/libs

@bors
Copy link
Contributor

bors commented Jun 14, 2017

☔ The latest upstream changes (presumably #42644) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton
Copy link
Member

Looks like the linkchecker also turned up errors :(

Copy link
Contributor

@mattico mattico left a 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"]

@murarth
Copy link
Contributor Author

murarth commented Jun 14, 2017

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 std::collections, so I just put a brief note and a link over there.

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Jun 14, 2017

📌 Commit eadda76 has been approved by alexcrichton

@joshlf
Copy link
Contributor

joshlf commented Jun 14, 2017

Sorry to be a wet blanked - and maybe there's something I'm missing here - but wouldn't it be better if collections were a separate no_std crate with each type taking an Allocator parameter so that they could be used in kernels/embedded/etc? Then maybe there could be another crate (maybe alloc itself) that re-exports all of the types with the standard allocator as the default value for the Allocator type parameter?

@alexcrichton
Copy link
Member

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

@joshlf
Copy link
Contributor

joshlf commented Jun 14, 2017

@alexcrichton Fair enough; as long as we leave open the possibility :)

@mattico
Copy link
Contributor

mattico commented Jun 14, 2017

@joshlf take a look at #42313

(sorry for the noise)

@aidanhs aidanhs added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 15, 2017
@joshlf
Copy link
Contributor

joshlf commented Jun 15, 2017

@mattico Yep, I've been making plenty of noise over there too :)

@bors
Copy link
Contributor

bors commented Jun 15, 2017

⌛ Testing commit eadda76 with merge 258ae6d...

bors added a commit that referenced this pull request Jun 15, 2017
Merge crate `collections` into `alloc`

This is a necessary step in order to merge #42565
@Ericson2314
Copy link
Contributor

Woah. Really scared about the end of fine-grain crates behind the facade.

@Ericson2314
Copy link
Contributor

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.

@Ericson2314
Copy link
Contributor

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.

@bors
Copy link
Contributor

bors commented Jun 15, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 258ae6d to master...

@bors bors merged commit eadda76 into rust-lang:master Jun 15, 2017
@bors bors mentioned this pull request Jun 15, 2017
10 tasks
@whitequark
Copy link
Member

I'm somewhat overloaded right now, so that will have to be someone else...

@murarth
Copy link
Contributor Author

murarth commented Jun 17, 2017

I wouldn't mind handling that. ~~~Should be a simple copy/paste of the re-exports in std.~~~ Err, it would actually need to mimic the former collections crate, but it should be relatively straightforward, anyway.

@alexcrichton: One question, though: Should the re-exports of the new collections be marked deprecated? Does the compiler even recognize and issue warnings for stability attributes on re-exports?

@alexcrichton
Copy link
Member

We can't handle the reexports themselves being deprecated, but I think it's fine to deprecate the collections crate as a whole.

bors added a commit that referenced this pull request Jun 17, 2017
Convert `Into<Box<[T]>> for Vec<T>` into `From<Vec<T>> for Box<[T]>`

As the `collections` crate has been merged into `alloc` in #42648 this impl is now possible. This is the final part of #42129 missing from #42227.
hawkw added a commit to sos-os/kernel that referenced this pull request Jun 18, 2017
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.
frewsxcv added a commit to frewsxcv/rust that referenced this pull request Jun 20, 2017
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.
mbrubeck added a commit to mbrubeck/rust-smallvec that referenced this pull request Jun 20, 2017
libcollections was deprecated in rust-lang/rust#42648 and its contents
were moved to liballoc.
mbrubeck added a commit to mbrubeck/rust-smallvec that referenced this pull request Jun 20, 2017
libcollections was deprecated in rust-lang/rust#42648 and its contents
were moved to liballoc.
mbrubeck added a commit to mbrubeck/rust-smallvec that referenced this pull request Jun 23, 2017
libcollections was deprecated in rust-lang/rust#42648 and its contents
were moved to liballoc.
mbrubeck added a commit to mbrubeck/rust-smallvec that referenced this pull request Jun 28, 2017
libcollections was deprecated in rust-lang/rust#42648 and its contents
were moved to liballoc.
bors added a commit that referenced this pull request Apr 11, 2018
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.
bors added a commit that referenced this pull request Apr 12, 2018
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.
@steveklabnik steveklabnik mentioned this pull request Dec 10, 2018
8 tasks
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 28, 2023
…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?
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 28, 2023
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?
plotskogwq added a commit to plotskogwq/curve25519-dalek that referenced this pull request Aug 10, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants