Somehow llvm is able to optimize this version of Vec::reserve
into dramatically faster than the old version. In micro-benchmarks
this was 2-10 times faster. It also shaved 14 minutes off of
rust's compile times.
Closes#19281.
Part of #18424
Adds `capacity()` function to VecMap, as per the collections reform.
(Salvaged from #19516, #19523, while we await an RFC regarding `reserve`/`reserve_index` for `VecMap`)
pop calls siftdown, siftdown calls siftdown_range, and siftdown_range
loops on an index that can start as low as 0 and approximately doubles
each iteration.
TrieSet doesn't yet have union, intersection, difference, and symmetric difference functions implemented. Luckily, TrieSet is largely similar to TreeSet, so I was able to reference the implementations of these functions in the latter, and adapt them as necessary to make them work for TrieSet.
One thing that I thought was interesting is that the Iterator yielded by `iter()` for TrieSet iterates over the set's values directly rather than references to the values (whereas I think in most cases I see the Iterator given by `iter()` iterating over immutable references), so for consistency within TrieSet's interface, all of these Iterators also iterate over the values directly. Let me know if all of these should be instead iterating over references.
At the same time remove the `pub use` of the variants in favor of accessing
through the enum type itself. This is a breaking change as the `Found` and
`NotFound` variants must now be imported through `BinarySearchResult` instead of
just `std::slice`.
[breaking-change]
Closes#19271
This is an initial pass at stabilizing the `iter` module. The module is
fairly large, but is also pretty polished, so most of the stabilization
leaves things as they are.
Some changes:
* Due to the new object safety rules, various traits needs to be split
into object-safe traits and extension traits. This includes `Iterator`
itself. While splitting up the traits adds some complexity, it will
also increase flexbility: once we have automatic impls of `Trait` for
trait objects over `Trait`, then things like the iterator adapters
will all work with trait objects.
* Iterator adapters that use up the entire iterator now take it by
value, which makes the semantics more clear and helps catch bugs. Due
to the splitting of Iterator, this does not affect trait objects. If
the underlying iterator is still desired for some reason, `by_ref` can
be used. (Note: this change had no fallout in the Rust distro except
for the useless mut lint.)
* In general, extension traits new and old are following an [in-progress
convention](rust-lang/rfcs#445). As such, they
are marked `unstable`.
* As usual, anything involving closures is `unstable` pending unboxed
closures.
* A few of the more esoteric/underdeveloped iterator forms (like
`RandomAccessIterator` and `MutableDoubleEndedIterator`, along with
various unfolds) are left experimental for now.
* The `order` submodule is left `experimental` because it will hopefully
be replaced by generalized comparison traits.
* "Leaf" iterators (like `Repeat` and `Counter`) are uniformly
constructed by free fns at the module level. That's because the types
are not otherwise of any significance (if we had `impl Trait`, you
wouldn't want to define a type at all).
Closes#17701
Due to renamings and splitting of traits, this is a:
[breaking-change]
This change applies the conventions to unwrap listed in [RFC 430][rfc] to rename
non-failing `unwrap` methods to `into_inner`. This is a breaking change, but all
`unwrap` methods are retained as `#[deprecated]` for the near future. To update
code rename `unwrap` method calls to `into_inner`.
[rfc]: https://github.com/rust-lang/rfcs/pull/430
[breaking-change]
cc #19091
At the same time remove the `pub use` of the variants in favor of accessing
through the enum type itself. This is a breaking change as the `Found` and
`NotFound` variants must now be imported through `BinarySearchResult` instead of
just `std::slice`.
[breaking-change]
Closes#19272
Whilst browsing the source for BinaryHeap, I saw a FIXME for implementing into_iter. I think, since the BinaryHeap is represented internally using just a Vec, just calling into_iter() on the BinaryHeap's data should be sufficient to do what we want here. If this actually isn't the right approach (e.g., I should write a struct MoveItems and appropriate implementation for BinaryHeap instead), let me know and I'll happily rework this.
Both of the tests that I have added pass. This is my first contribution to Rust, so please let me know any ways I can improve this PR!
A single impl supports all of `[T]`, `Vec<T>` and `CVec<T>`.
Once `Iterable` is implemented, we will prefer it to `SlicePrelude`.
But the `with_capacity()` part might become tricky.
This change applies the conventions to unwrap listed in [RFC 430][rfc] to rename
non-failing `unwrap` methods to `into_inner`. This is a breaking change, but all
`unwrap` methods are retained as `#[deprecated]` for the near future. To update
code rename `unwrap` method calls to `into_inner`.
[rfc]: https://github.com/rust-lang/rfcs/pull/430
[breaking-change]
Closes#13159
cc #19091
The impl for [T] also works as impl for slices in general.
By generalizing the impl of StrVector for Vec<Str> to that for
AsSlice<Str>, it becomes much more generic.
Once Iterable is implemented, we will prefer it to AsSlice.
But the with_capacity() part might become tricky.
Signed-off-by: NODA, Kai <nodakai@gmail.com>
This commit makes `Cow` more usable by allowing it to be applied to
unsized types (as was intended) and providing some basic `ToOwned`
implementations on slice types. It also corrects the documentation for
`Cow` to no longer mention `DerefMut`, and adds an example.
Closes#19123
This commit is an implementation of [RFC 240][rfc] when applied to the standard
library. It primarily deprecates the entirety of `string::raw`, `vec::raw`,
`slice::raw`, and `str::raw` in favor of associated functions, methods, and
other free functions. The detailed renaming is:
* slice::raw::buf_as_slice => slice::from_raw_buf
* slice::raw::mut_buf_as_slice => slice::from_raw_mut_buf
* slice::shift_ptr => deprecated with no replacement
* slice::pop_ptr => deprecated with no replacement
* str::raw::from_utf8 => str::from_utf8_unchecked
* str::raw::c_str_to_static_slice => str::from_c_str
* str::raw::slice_bytes => deprecated for slice_unchecked (slight semantic diff)
* str::raw::slice_unchecked => str.slice_unchecked
* string::raw::from_parts => String::from_raw_parts
* string::raw::from_buf_len => String::from_raw_buf_len
* string::raw::from_buf => String::from_raw_buf
* string::raw::from_utf8 => String::from_utf8_unchecked
* vec::raw::from_buf => Vec::from_raw_buf
All previous functions exist in their `#[deprecated]` form, and the deprecation
messages indicate how to migrate to the newer variants.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0240-unsafe-api-location.md
[breaking-change]
Closes#17863
This commit is an implementation of [RFC 240][rfc] when applied to the standard
library. It primarily deprecates the entirety of `string::raw`, `vec::raw`,
`slice::raw`, and `str::raw` in favor of associated functions, methods, and
other free functions. The detailed renaming is:
* slice::raw::buf_as_slice => slice::with_raw_buf
* slice::raw::mut_buf_as_slice => slice::with_raw_mut_buf
* slice::shift_ptr => deprecated with no replacement
* slice::pop_ptr => deprecated with no replacement
* str::raw::from_utf8 => str::from_utf8_unchecked
* str::raw::c_str_to_static_slice => str::from_c_str
* str::raw::slice_bytes => deprecated for slice_unchecked (slight semantic diff)
* str::raw::slice_unchecked => str.slice_unchecked
* string::raw::from_parts => String::from_raw_parts
* string::raw::from_buf_len => String::from_raw_buf_len
* string::raw::from_buf => String::from_raw_buf
* string::raw::from_utf8 => String::from_utf8_unchecked
* vec::raw::from_buf => Vec::from_raw_buf
All previous functions exist in their `#[deprecated]` form, and the deprecation
messages indicate how to migrate to the newer variants.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0240-unsafe-api-location.md
[breaking-change]
Closes#17863
'Numeric' is the proper name of the unicode character class,
and this frees up the word 'digit' for ascii use in libcore.
Since I'm going to rename `Char::is_digit_radix` to
`is_digit`, I am not leaving a deprecated method in place,
because that would just cause name clashes, as both
`Char` and `UnicodeChar` are in the prelude.
[breaking-change]
This PR completes the removal of the runtime system and green-threaded abstractions as part of implementing [RFC 230](https://github.com/rust-lang/rfcs/pull/230).
Specifically:
* It removes the `Runtime` trait, welding the scheduling infrastructure directly to native threads.
* It removes `libgreen` and `libnative` entirely.
* It rewrites `sync::mutex` as a trivial layer on top of native mutexes. Eventually, the two modules will be merged.
* It hides the vast majority of `std::rt`.
This completes the basic task of removing the runtime system (I/O and scheduling) and components that depend on it.
After this lands, a follow-up PR will pull the `rustrt` crate back into `std`, turn `std::task` into `std::thread` (with API changes to go along with it), and completely cut out the remaining startup/teardown sequence. Other changes, including new [TLS](https://github.com/rust-lang/rfcs/pull/461) and synchronization are in the RFC or pre-RFC phase.
Closes#17325Closes#18687
[breaking-change]
r? @alexcrichton
Previously, the entire runtime API surface was publicly exposed, but
that is neither necessary nor desirable. This commit hides most of the
module, using librustrt directly as needed. The arrangement will need to
be revisited when rustrt is pulled into std.
[breaking-change]
Closes#18415
This links [`std::str`](http://doc.rust-lang.org/std/str/index.html) documentation to [literals](http://doc.rust-lang.org/reference.html#literals) in the reference guide and collects examples of literals into one group at the beginning of the section. ~~The new tables are not exhaustive (some escapes were skipped) and so I try to link back to the respective sections where more detail is located.~~ The tables are are mostly exhaustive. I misunderstood some of the whitespace codes.
I don't think the tables actually look that nice if that's important and I'm not sure how it could be improved. I think it does do a good job of collecting available options together. I think listing the escapes together is particularly helpful because they vary with type and are embedded in paragraphs.
[EDIT]
The [ascii table](http://man-ascii.com/) is here and may be useful.
This commit makes `Cow` more usable by allowing it to be applied to
unsized types (as was intended) and providing some basic `ToOwned`
implementations on slice types. It also corrects the documentation for
`Cow` to no longer mention `DerefMut`, and adds an example.
This commit changes `AsSlice` to work on unsized types, and changes the
`impl` for `&[T]` to `[T]`. Aside from making the trait more general,
this also helps some ongoing work with method resolution changes.
This is a breaking change: code that uses generics bounded by `AsSlice`
will have to change. In particular, such code previously often took
arguments of type `V` where `V: AsSlice<T>` by value. These should now
be taken by reference:
```rust
fn foo<Sized? V: AsSlice<T>>(v: &V) { .. }
```
A few std lib functions have been changed accordingly.
[breaking-change]
`slice_shift_char` splits a `str` into it's leading `char` and the remainder of the `str`. Currently, it returns a `(Option<char>, &str)` such that:
"bar".slice_shift_char() => (Some('b'), "ar")
"ar".slice_shift_char() => (Some('a'), "r")
"r".slice_shift_char() => (Some('r'), "")
"".slice_shift_char() => (None, "")
This is a little odd. Either a `str` can be split into both a head and a tail or it cannot. So the return type should be `Option<(char, &str)>`. With the current behaviour, in the case of the empty string, the `str` returned is meaningless - it is always the empty string.
This PR changes `slice_shift_char` so that:
"bar".slice_shift_char() => Some(('b', "ar"))
"ar".slice_shift_char() => Some(('a', "r"))
"r".slice_shift_char() => Some(('r', ""))
"".slice_shift_char() => None
Following [the collections reform
RFC](https://github.com/rust-lang/rfcs/pull/235),
this commit adds a new `borrow` module to libcore.
The module contains traits for borrowing data (`BorrowFrom` and
`BorrowFromMut`),
generalized cloning (`ToOwned`), and a clone-on-write smartpointer (`Cow`).
This breaks code that referred to variant names in the same namespace as
their enum. Reexport the variants in the old location or alter code to
refer to the new locations:
```
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
=>
```
pub use self::Foo::{A, B};
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
or
```
pub enum Foo {
A,
B
}
fn main() {
let a = Foo::A;
}
```
[breaking-change]
`slice_shift_char` splits a `str` into it's leading `char` and the remainder
of the `str`. Currently, it returns a `(Option<char>, &str)` such that:
"bar".slice_shift_char() => (Some('b'), "ar")
"ar".slice_shift_char() => (Some('a'), "r")
"r".slice_shift_char() => (Some('r'), "")
"".slice_shift_char() => (None, "")
This is a little odd. Either a `str` can be split into both a head and a
tail or it cannot. So the return type should be `Option<(char, &str)>`.
With the current behaviour, in the case of the empty string, the `str`
returned is meaningless - it is always the empty string.
This commit changes slice_shift_char so that:
"bar".slice_shift_char() => Some(('b', "ar"))
"ar".slice_shift_char() => Some(('a', "r"))
"r".slice_shift_char() => Some(('r', ""))
"".slice_shift_char() => None
[breaking-change]
Fix for task in Metabug #18009 (Rebased version of https://github.com/rust-lang/rust/pull/18170)
This changes much of about how RingBuf functions. `lo`, `nelts` are replaced by a more traditional `head` and`tail`. The `Vec<Option<T>>` is replaced by a bare pointer that is managed by the `RingBuf` itself. This also expects the ring buffer to always be size that is a power of 2.
This change also includes a number of new tests to cover the some areas that could be of concern with manual memory management.
The benchmarks have been reworked since the old ones were benchmarking of the Ring buffers growth rather then the actual test.
The unit test suite have been expanded, and exposed some bugs in `fn get()` and `fn get_mut()`
## Benchmark
**Before:**
```
test ring_buf::tests::bench_grow_1025 ... bench: 8919 ns/iter (+/- 87)
test ring_buf::tests::bench_iter_1000 ... bench: 924 ns/iter (+/- 28)
test ring_buf::tests::bench_mut_iter_1000 ... bench: 918 ns/iter (+/- 6)
test ring_buf::tests::bench_new ... bench: 15 ns/iter (+/- 0)
test ring_buf::tests::bench_pop_100 ... bench: 294 ns/iter (+/- 9)
test ring_buf::tests::bench_pop_front_100 ... bench: 948 ns/iter (+/- 32)
test ring_buf::tests::bench_push_back_100 ... bench: 291 ns/iter (+/- 16)
test ring_buf::tests::bench_push_front_100 ... bench: 311 ns/iter (+/- 27
```
**After:**
```
test ring_buf::tests::bench_grow_1025 ... bench: 2209 ns/iter (+/- 169)
test ring_buf::tests::bench_iter_1000 ... bench: 534 ns/iter (+/- 27)
test ring_buf::tests::bench_mut_iter_1000 ... bench: 515 ns/iter (+/- 28)
test ring_buf::tests::bench_new ... bench: 11 ns/iter (+/- 0)
test ring_buf::tests::bench_pop_100 ... bench: 170 ns/iter (+/- 5)
test ring_buf::tests::bench_pop_front_100 ... bench: 171 ns/iter (+/- 11)
test ring_buf::tests::bench_push_back_100 ... bench: 172 ns/iter (+/- 13)
test ring_buf::tests::bench_push_front_100 ... bench: 158 ns/iter (+/- 12)
```
A recent change turned off inheritance for the #[stable] by default, but
failed to catch all the cases where this was being used in std. This
patch fixes that problem.
I found some occurrences of "failure" and "fails" in the documentation. I changed them to "panics" if it means a task panic. Otherwise I left it as is, or changed it to "errors" to clearly distinguish them.
Also, I made a minor fix that is breaking the layout of a module page. "Example" is shown in an irrelevant place from the following page: http://doc.rust-lang.org/std/os/index.html
-Adds unit tests for fn get() and fn get_mut() which are currently untested
-Adds unit tests to verify growth of the ringbuffer when reserve is called.
-Adds unit tests to confirm that dropping of items is correct
Move ringbuf to use a raw buffer instead of Option<T>
This implements a considerable portion of rust-lang/rfcs#369 (tracked in #18640). Some interpretations had to be made in order to get this to work. The breaking changes are listed below:
[breaking-change]
- `core::num::{Num, Unsigned, Primitive}` have been deprecated and their re-exports removed from the `{std, core}::prelude`.
- `core::num::{Zero, One, Bounded}` have been deprecated. Use the static methods on `core::num::{Float, Int}` instead. There is no equivalent to `Zero::is_zero`. Use `(==)` with `{Float, Int}::zero` instead.
- `Signed::abs_sub` has been moved to `std::num::FloatMath`, and is no longer implemented for signed integers.
- `core::num::Signed` has been removed, and its methods have been moved to `core::num::Float` and a new trait, `core::num::SignedInt`. The methods now take the `self` parameter by value.
- `core::num::{Saturating, CheckedAdd, CheckedSub, CheckedMul, CheckedDiv}` have been removed, and their methods moved to `core::num::Int`. Their parameters are now taken by value. This means that
- `std::time::Duration` no longer implements `core::num::{Zero, CheckedAdd, CheckedSub}` instead defining the required methods non-polymorphically.
- `core::num::{zero, one, abs, signum}` have been deprecated. Use their respective methods instead.
- The `core::num::{next_power_of_two, is_power_of_two, checked_next_power_of_two}` functions have been deprecated in favor of methods defined a new trait, `core::num::UnsignedInt`
- `core::iter::{AdditiveIterator, MultiplicativeIterator}` are now only implemented for the built-in numeric types.
- `core::iter::{range, range_inclusive, range_step, range_step_inclusive}` now require `core::num::Int` to be implemented for the type they a re parametrized over.
Throughout the docs, "failure" was replaced with "panics" if it means a
task panic. Otherwise, it remained as is, or changed to "errors" to
clearly differentiate it from a task panic.
Ensured that Extend & FromIterator are implemented for the libcollection.
Removed the fact that FromIterator had to be implemented in order to implement Extend, as it did not make sense for LruCache (it needs to be given a size and there are no Default for LruCache).
Changed the name from Extend to Extendable.
Part of #18424
* Renames/deprecates the simplest and most obvious methods
* Adds FIXME(conventions)s for outstanding work
* Marks "handled" methods as unstable
NOTE: the semantics of reserve and reserve_exact have changed!
Other methods have had their semantics changed as well, but in a
way that should obviously not typecheck if used incorrectly.
Lots of work and breakage to come, but this handles most of the core
APIs and most eggregious breakage. Future changes should *mostly* focus on
niche collections, APIs, or simply back-compat additions.
[breaking-change]
This commit renames a number of extension traits for slices and string
slices, now that they have been refactored for DST. In many cases,
multiple extension traits could now be consolidated. Further
consolidation will be possible with generalized where clauses.
The renamings are consistent with the [new `-Prelude`
suffix](https://github.com/rust-lang/rfcs/pull/344). There are probably
a few more candidates for being renamed this way, but that is left for
API stabilization of the relevant modules.
Because this renames traits, it is a:
[breaking-change]
However, I do not expect any code that currently uses the standard
library to actually break.
Closes#17917
Unicode characters and strings.
Use `\u0080`-`\u00ff` instead. ASCII/byte literals are unaffected.
This PR introduces a new function, `escape_default`, into the ASCII
module. This was necessary for the pretty printer to continue to
function.
RFC #326.
Closes#18062.
[breaking-change]
* Moves multi-collection files into their own directory, and splits them into seperate files
* Changes exports so that each collection has its own module
* Adds underscores to public modules and filenames to match standard naming conventions
(that is, treemap::{TreeMap, TreeSet} => tree_map::TreeMap, tree_set::TreeSet)
* Renames PriorityQueue to BinaryHeap
* Renames SmallIntMap to VecMap
* Miscellanious fallout fixes
[breaking-change]
As part of the collections reform RFC, this commit removes all collections
traits in favor of inherent methods on collections themselves. All methods
should continue to be available on all collections.
This is a breaking change with all of the collections traits being removed and
no longer being in the prelude. In order to update old code you should move the
trait implementations to inherent implementations directly on the type itself.
Note that some traits had default methods which will also need to be implemented
to maintain backwards compatibility.
[breaking-change]
cc #18424
- The signature of the `*_equiv` methods of `HashMap` and similar structures
have changed, and now require one less level of indirection. Change your code
from:
```
hashmap.find_equiv(&"Hello");
hashmap.find_equiv(&&[0u8, 1, 2]);
```
to:
```
hashmap.find_equiv("Hello");
hashmap.find_equiv(&[0u8, 1, 2]);
```
- The generic parameter `T` of the `Hasher::hash<T>` method have become
`Sized?`. Downstream code must add `Sized?` to that method in their
implementations. For example:
```
impl Hasher<FnvState> for FnvHasher {
fn hash<T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
}
```
must be changed to:
```
impl Hasher<FnvState> for FnvHasher {
fn hash<Sized? T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ }
// ^^^^^^
}
```
[breaking-change]
This commit enables implementations of IndexMut for a number of collections,
including Vec, RingBuf, SmallIntMap, TrieMap, TreeMap, and HashMap. At the same
time this deprecates the `get_mut` methods on vectors in favor of using the
indexing notation.
cc #18424
This commit adds the following impls:
impl<T> Deref<[T]> for Vec<T>
impl<T> DerefMut<[T]> for Vec<T>
impl Deref<str> for String
This commit also removes all duplicated inherent methods from vectors and
strings as implementations will now silently call through to the slice
implementation. Some breakage occurred at std and beneath due to inherent
methods removed in favor of those in the slice traits and std doesn't use its
own prelude,
cc #18424
https://github.com/rust-lang/rfcs/pull/221
The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.
Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.
We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.
To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:
grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'
You can of course also do this by hand.
[breaking-change]
This PR changes the signature of several methods from `foo(self, ...)` to `foo(&self, ...)`/`foo(&mut self, ...)`, but there is no breakage of the usage of these methods due to the autoref nature of `method.call()`s. This PR also removes the lifetime parameter from some traits (`Trait<'a>` -> `Trait`). These changes break any use of the extension traits for generic programming, but those traits are not meant to be used for generic programming in the first place. In the whole rust distribution there was only one misuse of a extension trait as a bound, which got corrected (the bound was unnecessary and got removed) as part of this PR.
I've kept the commits as small and self-contained as possible for reviewing sake, but I can squash them when the review is over.
See this [table] to get an idea of what's left to be done. I've already DSTified [`Show`][show] and I'm working on `Hash`, but bootstrapping those changes seem to require a more recent snapshot (#18259 does the trick)
r? @aturon
cc #16918
[show]: https://github.com/japaric/rust/commits/show
[table]: https://docs.google.com/spreadsheets/d/1MZ_iSNuzsoqeS-mtLXnj9m0hBYaH5jI8k9G_Ud8FT5g/edit?usp=sharing
This PR changes the signature of several methods from `foo(self, ...)` to
`foo(&self, ...)`/`foo(&mut self, ...)`, but there is no breakage of the usage
of these methods due to the autoref nature of `method.call()`s. This PR also
removes the lifetime parameter from some traits (`Trait<'a>` -> `Trait`). These
changes break any use of the extension traits for generic programming, but
those traits are not meant to be used for generic programming in the first
place. In the whole rust distribution there was only one misuse of a extension
trait as a bound, which got corrected (the bound was unnecessary and got
removed) as part of this PR.
[breaking-change]
Spring cleaning is here! In the Fall! This commit removes quite a large amount
of deprecated functionality from the standard libraries. I tried to ensure that
only old deprecated functionality was removed.
This is removing lots and lots of deprecated features, so this is a breaking
change. Please consult the deprecation messages of the deleted code to see how
to migrate code forward if it still needs migration.
[breaking-change]
I was going to write some doc in order to remove the #[allow(missing_doc)] but there was actually none missing.
I also removed a warning i didn't see in my last commit #18018
Linked to #18009
