| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
[breaking-change]
|
|
Just detected it while reading.
|
|
Add example for HashMap::entry()
|
|
|
|
An automated script was run against the `.rs` and `.md` files,
subsituting every occurrence of `task` with `thread`. In the `.rs`
files, only the texts in the comment blocks were affected.
|
|
Sweeten the two main HashMap/HashSet examples from [here](http://doc.rust-lang.org/std/collections/struct.HashMap.html) and [here](http://doc.rust-lang.org/std/collections/struct.HashSet.html) with some deref and loop sugar.
(I've only tested this using [this playpen][1].)
[1]: https://play.rust-lang.org/?code=fn%20main()%20%7B%0A%20%20%20%20use%20std%3A%3Acollections%3A%3AHashMap%3B%0A%20%20%20%20%0A%20%20%20%20%2F%2F%20type%20inference%20lets%20us%20omit%20an%20explicit%20type%20signature%20(which%0A%20%20%20%20%2F%2F%20would%20be%20%60HashMap%3C%26str%2C%20%26str%3E%60%20in%20this%20example).%0A%20%20%20%20let%20mut%20book_reviews%20%3D%20HashMap%3A%3Anew()%3B%0A%20%20%20%20%0A%20%20%20%20%2F%2F%20review%20some%20books.%0A%20%20%20%20book_reviews.insert(%22Adventures%20of%20Huckleberry%20Finn%22%2C%20%20%20%20%22My%20favorite%20book.%22)%3B%0A%20%20%20%20book_reviews.insert(%22Grimms%27%20Fairy%20Tales%22%2C%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%22Masterpiece.%22)%3B%0A%20%20%20%20book_reviews.insert(%22Pride%20and%20Prejudice%22%2C%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%22Very%20enjoyable.%22)%3B%0A%20%20%20%20book_reviews.insert(%22The%20Adventures%20of%20Sherlock%20Holmes%22%2C%20%22Eye%20lyked%20it%20alot.%22)%3B%0A%20%20%20%20%0A%20%20%20%20%2F%2F%20check%20for%20a%20specific%20one.%0A%20%20%20%20if%20!book_reviews.contains_key(%26(%22Les%20Mis%C3%A9rables%22))%20%7B%0A%20%20%20%20%20%20%20%20println!(%22We%27ve%20got%20%7B%7D%20reviews%2C%20but%20Les%20Mis%C3%A9rables%20ain%27t%20one.%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20book_reviews.len())%3B%0A%20%20%20%20%7D%0A%20%20%20%20%0A%20%20%20%20%2F%2F%20oops%2C%20this%20review%20has%20a%20lot%20of%20spelling%20mistakes%2C%20let%27s%20delete%20it.%0A%20%20%20%20book_reviews.remove(%26(%22The%20Adventures%20of%20Sherlock%20Holmes%22))%3B%0A%20%20%20%20%0A%20%20%20%20%2F%2F%20look%20up%20the%20values%20associated%20with%20some%20keys.%0A%20%20%20%20let%20to_find%20%3D%20%5B%22Pride%20and%20Prejudice%22%2C%20%22Alice%27s%20Adventure%20in%20Wonderland%22%5D%3B%0A%20%20%20%20for%20book%20in%20to_find.iter()%20%7B%0A%20%20%20%20%20%20%20%20match%20book_reviews.get(book)%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20Some(review)%20%3D%3E%20println!(%22%7B%7D%3A%20%7B%7D%22%2C%20*book%2C%20*review)%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20None%20%3D%3E%20println!(%22%7B%7D%20is%20unreviewed.%22%2C%20*book)%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%20%20%20%20%0A%20%20%20%20%2F%2F%20iterate%20over%20everything.%0A%20%20%20%20for%20(book%2C%20review)%20in%20book_reviews.iter()%20%7B%0A%20%20%20%20%20%20%20%20println!(%22%7B%7D%3A%20%5C%22%7B%7D%5C%22%22%2C%20*book%2C%20*review)%3B%0A%20%20%20%20%7D%0A%20%20%20%20%0A%7D
|
|
|
|
|
|
Since the hashmap and its hasher are implemented in different crates, we
currently can't benefit from inlining, which means that especially for
small, fixed size keys, there is a huge overhead in hash calculations,
because the compiler can't apply optimizations that only apply for these
keys.
Fixes the brainfuck benchmark in #24014.
|
|
These implementations were intended to be unstable, but currently the stability
attributes cannot handle a stable trait with an unstable `impl` block. This
commit also audits the rest of the standard library for explicitly-`#[unstable]`
impl blocks. No others were removed but some annotations were changed to
`#[stable]` as they're defacto stable anyway.
One particularly interesting `impl` marked `#[stable]` as part of this commit
is the `Add<&[T]>` impl for `Vec<T>`, which uses `push_all` and implicitly
clones all elements of the vector provided.
Closes #24791
|
|
Conflicts:
src/libcore/result.rs
|
|
This is an implementation of [RFC 1030][rfc] which adds these traits to the
prelude and additionally removes all inherent `into_iter` methods on collections
in favor of the trait implementation (which is now accessible by default).
[rfc]: https://github.com/rust-lang/rfcs/pull/1030
This is technically a breaking change due to the prelude additions and removal
of inherent methods, but it is expected that essentially no code breaks in
practice.
[breaking-change]
Closes #24538
|
|
This API was exercised in a few tests and mirrors the `from_str_radix`
functionality of the integer types.
|
|
|
|
|
|
This is an implementation of [RFC 1030][rfc] which adds these traits to the
prelude and additionally removes all inherent `into_iter` methods on collections
in favor of the trait implementation (which is now accessible by default).
[rfc]: https://github.com/rust-lang/rfcs/pull/1030
This is technically a breaking change due to the prelude additions and removal
of inherent methods, but it is expected that essentially no code breaks in
practice.
[breaking-change]
Closes #24538
|
|
|
|
Conflicts:
src/libstd/net/ip.rs
src/libstd/sys/unix/fs.rs
src/libstd/sys/unix/mod.rs
src/libstd/sys/windows/mod.rs
|
|
|
|
|
|
Signed-off-by: Tibor Benke <ihrwein@gmail.com>
|
|
* The `io::Seek` trait, and `SeekFrom` enum.
* The `Iterator::{partition, unsip}` methods.
* The `Vec::into_boxed_slice` method.
* The `LinkedList::append` method.
* The `{or_insert, or_insert_with` methods in the `Entry` APIs.
|
|
Fixes #23320
|
|
The collections debug helpers no longer prefix output with the
collection name, in line with the current conventions for Debug
implementations. Implementations that want to preserve the current
behavior can simply add a `try!(write!(fmt, "TypeName "));` at the
beginning of the `fmt` method.
[breaking-change]
|
|
All methods are inlined into Iterator with `Self: Sized` bounds to make
sure Iterator is still object safe.
[breaking-change]
|
|
Fixes #23320
|
|
Also convert [T]'s Debug impl. The behavior of the alternate flag here's
changing.
|
|
The collections debug helpers no longer prefix output with the
collection name, in line with the current conventions for Debug
implementations. Implementations that want to preserve the current
behavior can simply add a `try!(write!(fmt, "TypeName "));` at the
beginning of the `fmt` method.
[breaking-change]
|
|
Conflicts:
src/librustc/middle/ty.rs
src/librustc_trans/trans/adt.rs
src/librustc_typeck/check/mod.rs
src/libserialize/json.rs
src/test/run-pass/spawn-fn.rs
|
|
Conflicts:
src/libcollections/vec.rs
|
|
|
|
|
|
Now that support has been removed, all lingering use cases are renamed.
|
|
|
|
Conflicts:
src/compiletest/compiletest.rs
src/libcollections/lib.rs
src/librustc_back/lib.rs
src/libserialize/lib.rs
src/libstd/lib.rs
src/libtest/lib.rs
src/test/run-make/rustdoc-default-impl/foo.rs
src/test/run-pass/env-home-dir.rs
|
|
- Successful merges: #22954, #23119, #23509, #23561, #23590, #23607, #23608, #23618, #23622, #23639, #23641
- Failed merges: #23401
|
|
|
|
This commit marks as `#[stable]` the `Entry` types for the maps provided
by `std`. The main reason these had been left unstable previously was
uncertainty about an eventual trait design, but several plausible
designs have been proposed that all work fine with the current type definitions.
r? @Gankro
|
|
references. For collections whose keys are integers, we take both
references and by-value.
|
|
This commit removes the `IndexMut` impls on `HashMap` and `BTreeMap`, in
order to future-proof the API against the eventual inclusion of an
`IndexSet` trait.
Ideally, we would eventually be able to support:
```rust
map[owned_key] = val;
map[borrowed_key].mutating_method(arguments);
&mut map[borrowed_key];
```
but to keep the design space as unconstrained as possible, we do not
currently want to support `IndexMut`, in case some other strategy will
eventually be needed.
Code currently using mutating index notation can use `get_mut` instead.
[breaking-change]
Closes #23448
|
|
This commit marks as `#[stable]` the `Entry` types for the maps provided
by `std`. The main reason these had been left unstable previously was
uncertainty about an eventual trait design, but several plausible
designs have been proposed that all work fine with the current type definitions.
|
|
|
|
|
|
closes #23327
|
|
This brings comments in line with https://github.com/rust-lang/rfcs/blob/master/text/0505-api-comment-conventions.md#using-markdown
|
|
|
|
Many of the core rust libraries have places that rely on integer
wrapping behaviour. These places have been altered to use the wrapping_*
methods:
* core::hash::sip - A number of macros
* core::str - The `maximal_suffix` method in `TwoWaySearcher`
* rustc::util::nodemap - Implementation of FnvHash
* rustc_back::sha2 - A number of macros and other places
* rand::isaac - Isaac64Rng, changed to use the Wrapping helper type
Some places had "benign" underflow. This is when underflow or overflow
occurs, but the unspecified value is not used due to other conditions.
* collections::bit::Bitv - underflow when `self.nbits` is zero.
* collections::hash::{map,table} - Underflow when searching an empty
table. Did cause undefined behaviour in this case due to an
out-of-bounds ptr::offset based on the underflowed index. However the
resulting pointers would never be read from.
* syntax::ext::deriving::encodable - Underflow when calculating the
index of the last field in a variant with no fields.
These cases were altered to avoid the underflow, often by moving the
underflowing operation to a place where underflow could not happen.
There was one case that relied on the fact that unsigned arithmetic and
two's complement arithmetic are identical with wrapping semantics. This
was changed to use the wrapping_* methods.
Finally, the calculation of variant discriminants could overflow if the
preceeding discriminant was `U64_MAX`. The logic in `rustc::middle::ty`
for this was altered to avoid the overflow completely, while the
remaining places were changed to use wrapping methods. This is because
`rustc::middle::ty::enum_variants` now throws an error when the
calculated discriminant value overflows a `u64`.
This behaviour can be triggered by the following code:
```
enum Foo {
A = U64_MAX,
B
}
```
This commit also implements the remaining integer operators for
Wrapped<T>.
|
|
|